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ABSTRACT 


This  thesis  presents  a  discussion  o-f  automated  data  processing  and 
storage  in  a  n>'j1ti  level  secure  environment.  The  paper  covers  areas  such 
as  the  design  and  implementation  o-f  a  security  kernel;  the  DoD  Computer 
Security  Center's  criteria  -for  trusted  computer  systems  and  networks; 
and  risk  assessment  when  processsing  and  storing  sensitive  or  classi-fied 
data. 

One  o-f  the  primary  purposes  o-f  this  paper  is  to  serve  as  a  handy 
re-ference  -for  students  in  the  Command,  Control,  and  Communications 
curriculum  at  the  Naval  Postgraduate  School  who  will  research  multilevel 
security  and  secure  guard  applications  -following  the  acquisition  o-f  the 
Gemini  Trusted  Multiple  Microcomputer  Base  -for  the  Uargaming,  Research, 
and  Analysis  (W.A.R.)  lab. 

Additionally,  a  risk  assessment  o-f  the  W.A.R.  lab  was  conducted  and 
the  possibilities  o-f  converting  the  -facility  into  a  multilevel  secure 
computing  environment  were  investigated. 
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I.   INTRODUCTION 

The   rapid  expansion   o-f  i  n-format  i  on   systems  and  networks   in  the 
command  and  control  world  have  made  them  a  critical  linl<  in  the  national 
de+ense.   "Computers'  .  .  .   speed  and  un+ailing  accuracy  make  them  well 
suited  to  the  massive  in-formation  handling  tasks  in  battle  management 
■for:  shared  information  storage,  retrieval,  and  dissemination  systems; 
rapid  and  common  data  processing  systems;  and  e-f+icient  and  reliable 
communications  process  control."  [Re+.  l:p.  271]   Unfortunately,  the 
rapid  pace  of  technological  breakthrough  in  computing  systems  has  far 
outpaced  developments  in  computer  security.   Abuses  o+  computers  that 
were  not  designed  -from  the  ground  up  to  provide  security  currently 
represent  a  major  problem.   For  these  systems,  a  great  need  exists  tor  a 
•front-end  processor  to  authenticate  and  control  access  to  the  system  or 
i  ts  resources. 
A.   HISTORICAL  PERSPECTIVE 

In  the  mid-1950's  to  the  early  1960-s,  data  processing  was  usually 
con-fined  to  a  single  center.  Programs  were  brought  to  the  computer 
center  in  the  -form  o+  card  decks.  These  programs  were  batch  processed 
and  any  sensitive  or  classified  data  could  be  purged  prior  to  the  next 
user.  Since  there  was  no  sharing  o-f  resources,  physical  security  of  the 
sensitive  or  classified  data  and  assurance  of  a  cleared  memory  were  the 
major  components  of  any  security  policy. 
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As  more  powerful  and  -faster  computers  emerged  in  the  mid-1960's, 
"operating-systems"  evolved  to  allow  multiple  users.  This  was  a  result 
o-f  the  computers'  cost  and  the  -fact  that  human  operators  were  too  slow 
to  e  +  -f  i  c  i  entl  y  employ  the  machines.  Simple  operating  systems  selected 
which  jobs  would  run  on  a  priority  basis.  More  dynamic  operating 
systems  allowed  several  jobs  to  run  at  the  same  time  by  the  use  o-f 
"multiprogramming".  Even  more  sophisticated  yet  were  operating  systems 
that  allowed  "time-sharing".  Many  users  were  allowed  access  to  the 
computer  through  remote  terminals.  Although  all  o-f  these  users  were 
being  serviced  at  the  same  time,  each  user  had  the  illusion  o-f  being 
connected  to  a  dedicated  computer.  The  computer  was  now  under  the 
control  o-f  a  computer  operating  system  rather,  than  the  user.  These 
privileged  operating  systems  soon  became  the  target  o-f  malicious  users 
who  wanted  to  penetrate  the  operating  system  and  share  their  privileges. 
Suddenly,  computer  security  became  an  issue.  The  need  -for  "trustworthy" 
operating  systems  was  apparent. 
B.   COMPUTER  SECURITY  '  '    " 

"Computer  security  is  the  protection  o-f  computing  assets  or 
resources  and  computer-based  systems  against  accidental  and  deliberate 
threats  whose  occurrence  .Tia/  cause  losses  due  to  those  systems' 
non-availability,  lack  o-f  integrity,  or  lack  o-f  con-f  i  den  t  i  al  i  ty . " 
[Re-f.  2:p.  73 

1.   Phys  i  cal  Secur  i  ty 

This  is  the  most  basic  security  requirement  and  should  be 
a-f-forded  to  all  computer  systems  with  considerations  given  to  both  the 
internal   and  external   environments.    The  degree  to  which  physical 
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security  is  insured  is  dependent  upon  the  value  o-f  the  data  being 
protected.    Essentially,  most  ot   the  considerations  given   to   the 
physical  security  o-f  computers  is  not  unique  to  computers  and  is  closely 
related  to  the  security  given  classified  documents. 
2.   Security  Modes  o-f  Operation 

In-formation   can   also  be   protected  -from  compromise   by   the 

particular  security  mode  o-f  operation  that  is  selected.   The  Department 

o-f  De-fense  recognizes  -five  distinct  security  modes  o-f  operation.   These 

modes  are  enumerated  in  Appendi;<  A.   Security  modes  o-f  operation  -fail 

into  one  o-f  two  general  categories:  dedicated  usage  or  shared  resources. 

In  the  dedicated  mode,  access  to  the  computer  system  is 
restricted  to  an  individual  user  or  homogeneous  group  o-f  users  that  have 
access  to  all  the  in-formation  that  is  processed  or  stored  on  the  system. 
There  is  no  danger  that  subversion  or  -failure  of  the  computer  will 
result  in  the  compromise  o-f  sensitive  i  n-format  i  on .  The  computer 
security  problem  in  this  category  is  one  o-f  physical  security  and 
personnel  screening. 

Resources  are  most  o-f  ten  shared  among  groups  o-f  users  with  a 
common  level  o-f  trust  to  add  some  -flexibility  to  the  dedicated  mode. 
Again,  physical  security  and  personnel  screening  are  paramount  to  such  a 
security  policy  and  all  resources/terminals  tied  to  the  system  must  be 
a-f-forded  the  same  degree  o-f  protection.  Todays  problem  is  one  o-f  being 
able  to  share  computer  resources  among  users  or  groups  o-f  users  that  do 
not  share  the  same  level  o-f  trust  (multilevel  security). 
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3.  Communications  Security 

Remote  and  interactive  access  to  computers  give  rise  to  a  new 
threat  to  information  security.  Information  that  is  being  transmitted 
through  any  medium  is  susceptible  to  interception.  The  most  common 
means  to  combat  this  threat  is  data  encryption.  This  technique  involves 
the  use  of  encryption  algorithms  usually  seeded  by  some  variable  key  to 
produce  un  i  ntel  1  i  gbl  e  code  prior  to  transmission.  This  code  can  theri  De 
deciphered  upon  receipt. 

Although  not  strictly  a  communications  security  problem, 
emanations  security  (TEMPEST  threat)  is  mentioned  at  this  point  because 
the  same  principles  of  sending  and  receiving  electromagnetic  signals  are 
involved.  Emanations  are  electromagnetic  energy  by-products  of 
computing  devices  that  are  usually  most  severe  when  communicating  with 
peripherals.  These  emanations  can  be  detected  by  sensitive  devices  for 
several  hundred  yards.  Cathode  ray  tubes  (CRT's)  are  especially  noted 
for  their  signatures.  Protection,  such  as  shielding,  is  technically 
simple  but  often  awkward  and  expensive  and  operationally  complex. 

4.  Authent  i  cat  i  on 

Authentication  systems  have  been  in  use  for  a  relatively  long 
time.  They  are  absolutely  essential  as  an  access  controller  in  an 
environment  of  shared  resources.  The  most  commonly  used  is  that  of  the 
password.  "The  password  serves  essentially  as  a  "combination"  to  a 
"lock"  allowing  access  to  the  system."  [Ref.  l:p.  274]  This  type  of 
approach  is  particularly  vulnerable  when  simple  passwords  are  used, 
compromise  of  the  password  is  allowed,  or  a  computerized  password 
generator  is  used  to  determine  the  password  (especially  if  the  system 
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does  not  time  out  a+ter  a  number  o-f  attempts).  Finally,  this  type  o+ 
access  control  permits  or  prevents  access  to  the  computer  system,  but  it 
•fails  to  distinguish  between  the  various  authorised  users.  This 
■function  is  dependent  upon  the  internal  controls  ot  the  computer  itselt. 

This  technical  weakness  can  be  overcome  by  the  development  o-f  a 
wel  1 --formul  ated  security  policy  that  is  conveyed  to  the  system 
designers.  The  system  can  then  en-force  access  control  mechanisms  based 
on  the  authorizations  it  has  been  given.  A  trusted  system  is  the  result 
when  this  process  has  been  success-ful  1  y  accomplished  and  a  wel  1 -de-f  i  ned 
policy  regarding  access  to  sensitive  i  n-format  i  on  is  en-forced  by  the 
system. 

The  main  requirement  -for  a  security  policy  that  is  to  be 
integrated  into  a  trusted  system  is  the  need  -for  security  "labels"  -for 
all  in-formation  to  indicate  its  sensitivity  and  -for  all  users  to 
indicate  their  authorization  -for  access.  Recent  research  has  shown  that 
an  e-f-fective  labelling  policy  can  be  implemented  with  a  two-part  label. 
"The  -first  part  represents  a  hierarchical  sensitivity  level,  such  as 
confidential,  secret  or  top  secret;  the  second,  user  community  o-f 
interest  or  compartment  label."  [Re-f.  l:p.  2753 

An  operating  system  must  maintain  these  labels  internally  ^o 
that  it  can  en-force  the  security  policy.  The  technology  is  currently 
available,  along  with  mathematical  models  and  formal  specifications,  to 
accomplish  this  task.  The  most  predominant  approach  is  that  o-f  the 
security  kernel  (to  be  explained  later).  Honeywell  Information  Systems, 
Inc.  and  Gemini  Computers,  Inc.  are  on  the  cutting  edge  o-f  this 
technology  and  are  among  the  -few  vendors  actively  marketing  such  trusted 
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systems.  This  paper  concentrates  on  these  trusted  systems  and  their  use 
as  a  multileuel  security  system  and/or  a  secure  guard. 
C.   DEVELOPMENT  OF  MULTILEVEL  SECURE  SYSTEMS 

The  need  for  systems  that  can  provide  a  multilevel  secure 
environment  have  been  well  established  as  a  result  of  the  advent  o  + 
distributed  computing  systems  and  shared  resources.  Alternatives 
';benign  environment  or  "system-high"  concept)  to  such  systems  are 
unacceptable  -for  many  Department  o-f  Defense  applications.  The 
alternatives  to  a  multilevel  secure  system  are  defined  in  DoD  Directive 
2500.28: 

a.  clearing  all  users  to  the  highest  level  of  information  on 
the  system  and  processing  all  work  at  that  level,  or 

b.  processing  jobs  of  dif-ferent  levels  at  different  times  - 
requiring  a  complete  system  change  or  sanitization  each  time 
the  level  is  changed. 

A  system  operating   in  either   of   these  unilevel   modes   is  usually 

operating  "system  high."   Either  of  these  choices  is  inefficient  and 

cost  1 y . 

In  1968-1974,  "Tiger  Teams"  were  formed  to  attempt  penetration  of 
access  control  mechanisms  o-f  existing  operating  systems.  Remarkably, 
penetration  was  accomplished  on  every  commercial  operating  svstem.  The 
research  community  became  so  concerned  that  public  awareness  was 
heightened  and  such  issues  were  the  impetus  for  the  development  of  the 
security  kernel  which  provides  the  basis  for  multilevel  security. 

In  1972,  the  Air  Force  Electronic  Systems  Division  (E3D)  conducted 
an  in-depth  analysis  o-f  the  requirements  for  a  security  system.  The 
basic  concept  o-f  a  re-ference  monitor  or  a  security  kernel  was  the 
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result.  This  concept  was  the  -foundation  -for  work  at  the  Massachusetts 
Institute  o-f  Technology,  the  MITRE  Corporation,  and  Honeywell 
In-formation  System  to  begin  restructuring  the  MULTICS  operating  system. 

In  1977,  the  Department  oi  De-fense  initiated  an  e  +  +  ort  to  produce 
the  DoD  Kernel  ized  Secure  Operating  System  (KSOS)  which  would  emulate 
the  UNIX  operating  system.  The  UNIX  operating  system  was  chosen  because 
0+  this  operating  system's  use  on  the  popular  PDP-11  series  ot 
computers.  The  implementation  phase  was  contracted  out  to  the  Ford 
Aerospace  and  Communications  Corporation  in  May,  1973.  This  project 
became  known  as  KSOS-11  and  -further  development  o-f  the  operating  system 
was  oriented  towards  the  DEC  PDP-11/70. 

In  a  joint  ef-fort  with  the  Air  Force,  Honeywell  In-format  i.on  Systems 
began  developing  KSOS-6  in  October,  1977.  This  e-f-fort  was  a 
continuation  o-f  the  restructuring  o-f  the  MULTICS  operating  system. 
Research  was  stop  and  go  based  on  budgetary  and  other  limitations. 
However,  a  standard  commercial  product  called  the  Secure  Communications 
Processor  (SCOMP)  was  the  -final  result.  The  system  is  based  upon 
Honeywell's  DPS  6  16-bit  minicomputer  and  the  MULTICS  operating  system. 
SCOMP  has  been  verified  by  the  DoD  Computer  Security  Center  as  having  an 
Al  level  o-f  security.  A  discussion  o-f  the  DoD  Computer  Security 
Centers  criteria  -for  the  various  levels  o-f  security  will  be  presented 
i  n  Chap  ter  3 . 

One  0+  the  latest  systems  to  be  -fielded  is  the  Gemini  Trusted 
Multiple  Microcomputer  Base  by  Gemini  Computers,  Inc.  A  microcomputer 
was  chosen  as  the  base  because  it  holds  great  promise  serving  as  a 
-front-end  processor  because  o-f  its  physical  separation  and  its  small 
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operating  system.  In  the  role  as  a  -front-end  processor  tor 
communications,  it  can  easily  handle  encryption,  decryption,  and  sending 
and  receiving.  This  system  is  currently  being  evaluated  -for  a  B3  level 
o-f  security  and  will  be  discussed  later  in  this  paper. 

Much  research  on  multilevel   secure  and  guard  systems  was  dent 
concurrently  with  the  above  e-ftorts  and  much  has  been  done  since.  For  a 
more  complete  look  at  these  and  other  e-f  +  orts,  refer  to  Appendix  C 
[Re+.  3:  pp.  90-93].  This  in-formation  is  current  as  o-f  July  1933, 
D.   OBJECTI'v'ES 

The  primary  objective  o-f  this  paper  is  to  serve  as  a  re-ference  on 
the  concept  o-f  multilevel  security  -for  students  in  the  Command,  Control, 
and  Communications  curriculum  at  the  Naval  Postgraduate  School  who  will 
conduct  research  on  the  Gemini  Trusted  Multiple  Microcomputer  Base  that 
is  scheduled  to  be  purchased  -for  the  U.A.R.  lab  during  the  current 
•fiscal  year.  Additionally,  an  investigation  will  be  conducted  to 
determine  the  utility  o-f  this  system  (other  than  research)  in  the  lab. 

Since  the  re-ference  monitor  concept  (and  spec  i -f  i  cal  1  y  the  security 
kernel)  is  the  most  widely  accepted  model  -for  multilevel  systems,  a 
discussion  o-f  the  design  and  implementation  o-f  such  models  will  be 
presented.  This  discussion  details  the  requirements  -for  the  security 
kernel  and  presents  various  ver  i -f  i  cat  i  on  techniques. 

The  combination  o-f  hardware  and  so-ftware  -for  the  purpose  o-f 
en  +  orcing  a  security  policy  is  the  basis  -for  the  trusted  computer  system 
or  network.  The  criteria  established  by  the  Department  o-f  De-fense 
Computer  Security  Center  -for  evaluating  these  trusted  systems  is 
examined  in  detail  since  they  have  tremendous  impact  on  all  computer 
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systems  and  networks  in  the  Department  o+  Defense  that  process  or  store 
sensitive  information. 

Much  o-f  the  in-formation  concerning  trusted  computer  systems  and 
networks  is  necessary  -for  the  understanding  o-f  the  discussion  of  risk 
assessment.  Risk  assessment  is  an  attempt  to  evaluate  the  level  of  risk 
inherent  to  a  system  based  upon  the  computing  environment.  Two  methods 
0+  risk  assessment  will  be  compared  and  contrasted.  Risk  assessment 
usually  involves  determining  the  security  level  o+  the  user  and  the 
sensitivity  o-f  the  in-formation  that  is  being  stored  or  processed  on  a 
system.  Throughout  this  paper  the  term  "security  level"  will  be  used  to 
denote  the  combination  o-f  clearance  (or  cl  assi -f  i  cat  i  on)  and  -formal 
compartment  (or  category  set).  Appendix  B  lists  the  security  clearances 
currently  recognized  by  the  DoD  Computer  Security  Center. 

Finally,  a  risk  assessment  o-f  the  l,v)argami  ng.  Research,  and  Analysis 
(W.A.R.)  Lab  will  be  presented.  These  -findings  will  help  support  an 
investigation  o-f  the  integration  o-f  the  Gemini  Trusted  Multiple 
Microcomputer  Base  into  the  U.A.R.  lab  . 
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II .  SECURITY  KERNEL  DESIGN  AND  IMPLEMENTATION 

A  revietA*  o-f  design  and  implementation  guidelines  -for  the  security 
kernel  is  relevant  -for  any  discussion  o-f  multilevel  security.  Most 
experts  agree  that,  at  the  present  time,  the  security  kernel  concept 
(introduced  by  Roger  R.  Schell  in  1972)  is  the  most  viable  approach  to 
meeting  security  requirements  wherever  the  need  exists  for  a  system  that 
processes  shared  information.  In  1974,  MITRE  successfully  tested  a 
security  kernel  consisting  of  only  twenty  primitive  subroutines  to 
manage  physical  resources  and  enforce  protection  constraints  to  prove 
that  this  concept  was  valid. 
A.   THE  REFERENCE  MONITOR  CONCEPT 

The  security  kernel  approach  is  based  on  the  reference  monitor 
concept  adapted  from  the  models  of  Butler  Lampson  (Figure  2.1)  CRef.  4: 
p.  153.  "A  reference  monitor  is  a  computer  system  component  that  checks 
each  reference  by  a  subject  (user  or  program)  to  an  object  (file, 
device,  user,  or  program)  and  determines  whether  the  access  is  valid 
under  the  system's  security  policy.  To  be  effective,  such  a  mechanism 
must  be  invoked  on  every  reference,  must  be  small  enough  so  that  its 
correctness  can  be  assured,  and  must  be  tamperproof . "  [Ref .  3:p.  88] 

The  security  kernel  can  best  be  described  as  the  hardware  and 
software  that  transforms  the  abstract  concept  of  a  reference  monitor 
into  the  reality  of  a  functional  security  system  (Figure  2.2)  [Ref.  4: 
p.  17].   During  the  design  and  implementation  of  the  security  kernel, 
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total  adherence  to  the  -following  three  engineering  principles  must  be 
observed  -  completeness,  isolation,  and  yer i t i abi 1 i ty .  Every  access  to 
system  in-formation  must  be  mediated  by  the  kernel  (completeness).  The 
kernel  must  also  be  su-f -f  i  c  i  ent  1  y  protected  to  prevent  tampering 
(isolation).  Finally,  there  must  be  a  close  correlation  between  the 
•formal  security  policy  and  the  e-f-fect  i  veness  o-f  the  security  kernel 
(yer  i -f  i  abi  1  i  ty)  .  The  completeness  and  isolation  requirements  are  best 
met  with  hardware  -foundations  and  ver  i -f  i  abi  1  i  ty  strengthened  by  a  -formal 
development  methodology  [Re-f.  4:p.  153. 

When  the  need  -for  a  "secure"  system  arises,  a  list  o-f  demands  that 
would  insure  the  desired  level  o-f  security  must  be  established.  Once 
this  has  been  accomplished,  these  demands  provide  the  basis  -for  the 
establishment  o-f  a  -formal  security  policy.  All  the  permissible  modes  o-f 
access  between  all  subjects  and  objects  must  be  addressed.  These  steps 
must  precede  the  development  o-f  a  kernel-based  system  and  this  -formal 
policy  is  a  primary  distinction  between  the  security  kernel-based  system 
and  other  e-f-forts  to  develop  security-relevant  operating  systems. 
Concisely,  the  development  o-f  the  security  kernel-based  system 
encompasses  both  policy  and  mechanism. 

The  security  policy  is  best  described  by  a  set  o-f  mathematical 
relationships  which  provide  the  basis  -for  a  -formal  security  model.  In 
order  to  be  su-f-f  i  c  i  ent ,  the  model  must  de-fine  the  overall  protection 
behavior  o-f  the  system  as  a  whole  and  present  a  "security  theorem"  to 
insure  that  the  behavior  o-f  the  model  always  complies  with  the  security 
requirements  o-f  the  applicable  policy  [Re-f.  4:p.  153.  The  policy  must 
also  address  both  discretionary  access  rules  (applicable  to  all  users) 
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and  nondi scret i onary  access  rules  (optional  rules  applicable  to  certain 
users) . 

1 .  The  Bell  and  LaPadula  Model 

The  model  most  widely  used  -for  security  kernel  development  is 
re-ferred  to  as  the  Bell  and  LaPadula  model  which  is  the  product  o-f  early 
security  kernel  work  at  MITRE  and  Case  Western  Reserve  University.  This 
model  represents  the  kernel  as  a  -finite  state  machine  and  de-fines  rules 
-for  allowable  transitions  -from  one  secure  state  to  another.  Within  the 
model,  an  access  class  (a  security  identi-fier)  is  assigned  to  each 
subject  and  object  o-f  the  re-ference  monitor.  Allowable  access  to 
objects  is  made  by  comparing  the  access  class  o-f  both  subjects  and 
objects  at  each  transition  state.  The  access  classes  are  organized  in  a 
mathematical  structure  called  a  lattice  or  protection  matrix.  The 
lattice  arrangement  de-fines  relationships  among  the  access  classes  to 
determine  i -f  one  access  class  is  greater  than,  less  than,  equal  to,  or 
not  comparable  to  another  class. 

Figure  2.3  [Re-f.  5:p.  212]  shows  a  hypothetical  representation 
o-f  a  protection  matrix  access  diagram  located  within  a  security  kernel. 
In  this  example,  User  B  is  considered  to  be  the  system  administrator. 
It  IS  clear  that  his  privileges  -far  exceed  those  o-f  User  A.  Also,  this 
representation  shows  that  other  programs  or  -functions,  such  as  the 
Editor  Command  Module,  are  allowed  to  operate  within  established  limits. 
Such  an  access  matrix  must  reside  in  the  security  kernel  to  insure  its 
i  ntegr  i  ty . 

The  model  contains  two  -fundamental  nondi  scret  i  onary  rules  - 
simple  security  condition  and  *-property.   The  simple  security  condition 
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allows  a  subject  at  a  given  security  level  to  have  read  access  only  to 
objects  at  the  same  or  lower  security  levels  (no  read  up).  Simply 
stated,  this  rule  prevents  unauthorized  personnel  -from  directly  viewing 
in-formation  -for  which  they  do  not  have  proper  access.  The  *-property 
prevents  a  subject  -from  having  write  access  to  objects  at  lower  security 
levels  (no  write  down).  This  rule  was  established  to  combat  "Trojan 
horse"  so-ftware  and  prevents  users  -from  unauthorized  indirect  viewing  o  + 
i  n-format  i  on  . 

The  model  also  includes  rules  to  protect  the  integrity  o+  the 
system^s  in+ormation  and  to  prevent  improper  alteration.  Subjects  o+ 
one  access  class  cannot  alter  objects  located  in  a  higher  class. 
Conversely,  a  subject  o-f  one  access  class  cannot  be  altered  by  objects 
o-f  a  lower  access  class. 

Provisions  also  exist  in  the  model  -for  discretionary  access. 
Authorized  users  and  programs  can  arbitrarily  grant  and  revol<e  access  to 
in-formation  based  on  user  names  or  other  in-formation. 

One  limitation  o-f  the  Bell  and  LaPadula  model,  as  with  most 
other  models,  is  the  lack  o-f  sa-feguards  against  denial  o-f  service. 
Denial  o-f  service  is  the  threat  o-f  intentional  or  unintentional 
disruption  or  degradation  o-f  service.  However,  the  inclusion  o-f  a 
security  kernel  does  not  a-f-fect  the  system^s  susceptibility  to  the 
threat  o-f  denial  o-f  service.  This  shortcoming  is  attributable  to  the 
di-f-ficulty  o-f  establishing  a  mathematical  model  to  represent  the  rules. 
B.   THE  DE'v'ELOPMENT  PROCESS 

Once  a   security  policy  has  been  -formalized  and  an  appropriate  model 
has  been  selected,  the  development  process  must  be  divided  into  small 
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increments  -for  implementation.  "One  common  technique  is  to  apply  a 
hierarchy  o-f  abstract  spec  i -f  i  cat  i  ons  to  the  design  o-f  the  security 
kernel.  For  each  step,  it  is  important  to  demonstrate  security  so  that 
we  have  con-fidence  in  the  security  o-f  the  -final  system."  [Re-f.  4:p.  163 
Figure  2.4  is  a  depiction  o-f  the  integration  o-f  the  model,  the  hierarchy 
o-f  spec  i -f  i  cat  ions,  and  the  high-level  language  implementation  [Re-f.  4: 
p.  171. 

Three  classes  o-f  -formal  ver  i -f  i  cat  i  on  techniques  during  the  kernel 
development  process  are  also  shown  in  Figure  2.4.  The  -first  class  is 
used  to  prove  that  the  kernel  responds  as  outlined  in  the  -formal 
high-level  inter-face  spec  i -f  i  cat  i  on  .  Security  -flow  analysis  is  o-ften 
used  to  analyze  in-formation  -flow  in  a  spec  i -f  i  cat  i  on  .  The  second  class 
o-f  ver  i -f  i  cat  i  on  tests  the  correctness  o-f  mappings  between  intermediate 
spec  i -f  i  cat  i  ons  in  the  hierarchy  and  inter-face  spec  i -f  i  cat  i  ons  .  The  third 
and  most  traditional  technique  is  the  ver  i -f  i  cat  i  on  o-f  implementation  to 
spec  i  -f  icat  i  on  . 

The  kernel  provides  a  relatively  small  subset  o-f  the  operating 
system's  -functions.  The  kernel  primitives  that  provide  the  inter-face  o-f 
this  subset  to  the  remainder  o-f  the  operating  system  are  o-ften  re-ferred 
to  as  the  supervisor.  General -purpose  operating  system  -functions  used 
by  the  applications  are  provided  by  the  supervisor  primitives. 

Functional  areas  such  as  process  management,  -file  system  management 
-for  segments,  and  I/O  control  comprise  the  operating  system.  Each  o-f 
these  areas  possibly  have  security  relevant  -functions  that  must  be  in 
the  security  kernel.  The  policy  model  should  identi-fy  these  security 
relevant  -functions.   O-f  particular  importance  is  the  kernel's  role  in 
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managing  system  resources  such  as  memory  and  disk  space  that  are  shared 
by  multiple  users.  These  -functions  are  located  in  the  kernel  because 
they  must  be  virtual  (realized  by  the  combination  o-f  hardware  and 
so-ftware)  in  order  to  hide  their  location  -from  untrusted  so-ftware.  It 
is  permissible  for  any  utility  controlling  anything  not  shared  by  users 
to  be  located  outside  the  kernel  (in  the  supervisor). 

The  basic  security  model  that  has  been  described  thus  tar  is 
rudimentary  and  most  likely  the  greatest  need  exists  -for  a  system  that 
can  be  tailored  to  meet  speci-fic  requirements  that  may  change  -from  time 
to  time.  A  kernel  that  is  written  so  that  it  is  adaptable  usually  has  a 
group  o-f  inter-faces  that  can  be  invoked  by  individuals/programs  with 
special  privileges  -  trusted  subjects.  Internal  identi-fiers  such  as 
privilege  indicators  allow  actions  such  as  certain  system  maintenance 
activities  and  access  control  -for  nontrusted  subjects  (Figure  2.2) 
[Re-f.  4:p.  17].  Trusted  subjects  utilize  trusted  processes  and  trusted 
-functions  to  per-form  such  routine  tasks  as  maintenance  o-f  the  system's 
access  roster  and  the  upgrading  or  downgrading  o-f  classi-fied  material 
when  appropriate. 

1 .   Security  Kernel  Design  and  Implementation 

The  design  o-f  the  security  kernel  can  approach  two  extremes  when 
considering  the  degree  to  which  the  kernel  implementation  is  to  be 
-founded  in  hardware.  At  one  extreme,  the  kernel  is  entirely  written  in 
so-ftware  and  can  be  run  on  any  conventional  machine.  In  this  case,  the 
kernel  interprets  every  user  instruction  and  disallows  direct  user 
instructions  to  hardware.  The  only  hardware  involvement  is  its 
execution  o-f  the  kernel  so-ftware.    The  other  extreme   is  the   total 
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implementation  o-f  the  kernel  as  hardware  instructions  which  places 
absolute  responsibility  -for  security  on  system  architecture.  Obuiously, 
tradeo-f-fs  must  be  made  between  hardware  and  so-ftware  with  respect  to 
complexity,  size,  and  per-formance . 

Spec  i -fie  hardware  and  so-ftware  mechanisms  -from  -four  general 
architectural  areas  have  contributed  to  varying  degrees  to  supporting  a 
kernel -based  general -purpose  operating  system.  These  -four  architectural 
areas  are:  explicit  processes,  memory  protection,  execution  domains,  and 
I/O  mediation  [Re-f.  4:p.  183. 

Explicit  processes  re-fer  to  the  need  -for  support  -for  multiple 
processes  (multiprogramming)  and  interprocess  communications.  Access 
decisions  -for  subjects  are  made  on  the  basis  o-f  the  user's 
i  dent  i  +  i  cat  i  on  and  access  class.  These  two  identi-fiers  must  be 
impossible  to  counter-feit  and  are  tied  to  each  process.  .In  a"  jn-line 
system,  multiple  users  must  be  serviced,  thus  the  kernel  must  support 
multiple  simultaneous  processes.  This  creates  the  need  -for  a  greater 
number  ot  process  switches  and  makes  e-f-ficient  process-switching 
mechanisms  such  as  high  speed  memory  more  desirable. 

Memory  protection  requires  large  segmented  virtual  memory, 
access  control  to  memory,  and  explicitly  identi-fied  objects.  Memory  is 
the  usual  realization  o-f  the  re-ference  monitor  concept  o-f  storage 
object.  Virtual  memory  and  the  use  o-f  some  -form  o-f  descriptor  are 
commonly  used  together  to  serve  as  an  interpretive  mechanism  to  mediate 
all  access  to  memory. 

All  in-formation  within  the  system  must  be  represented  by 
distinct,  i  dent  i -f  i  abl  e  objects.   The  virtual  address  space  o-f  an  object 
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includes  more  than  one  object.  Each  has  its  own  distinct  logical 
attributes  such  as  size,  access  mode,  and  access  class.  This  logically 
distinct  memory  is  called  a  segment. 

Virtual  memory  segmentation  is  usually  supported  by  hardware. 
The  mapping  -for  segments  to  virtual  address  is  controlled  by  a 
descriptor.  This  descriptor  has  not  only  logical  attributes  but 
contains  both  a  physical  base  address  and  a  segment  size  which  uniquely 
identifies  each  segment.  The  segment  descriptor  must  support  the  access 
modes  o-f  at  least  null,  read,  and  read-write  -for  each  segment  in  order 
to  provide  adequate  discretionary  and  nondi scret i onary  access  policies. 
These  segment  descriptors  are  managed  by  the  security  kernel  software. 
However,  the  address-mapping  hardware  still  plays  a  significant  role-  in 
the  actual  access  mediation  process. 

Although  access  to  segments  is  dependent  upon  unique 
descriptors,  the  possibility  o-f  an  unintentional  leakage  o+  in-formation 
by  use  o-f  control  in-formation  such  as  -file  names  and  attributes  and 
system  variables  maintained  within  the  kernel  database  still  exists. 
Strict  design  and  ver  i -f  i  cat  i  on  techniques  can  prevent  or  detect  this 
de-ficiency.  The  discovery  o-f  such  a  leakage  channel  late  in  the 
kernels  development  is  a  -formidable  problem  -for  the  kernel  designer. 

Execution  domains  are  necessary  -for  the  isolation  and 
protection  o-f  the  security  kernel  mechanism.  In  order  -for  security 
kernel  -functions  to  be  invoked,  the  total  address  space  o-f  the  process 
must  include  the  programs  and  data  o-f  the  security  kernel.  Uhen  the 
process  must  access  segment  descriptors,  it  is  necessary  -for  this 
execution  to  take  place  in  the  kernel  only.   This  requires  a  separate 
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execution  domain  for  the  security  kernel.  It  is  also  desirable  to  keep 
the  supervisor  separated  -from  the  applications  software.  A  domain 
structure  with  three  hierarchical  domains  (kernel,  supervisor,  and  user) 
is  necessary  to  keep  the  user  and  the  operating  system  separated. 

Efficient  transfer  of  control  between  domains  is  a  desirable 
feature  because  of  the  vast  number  of  calls  a  process  makes  to  the 
kernel  and  the  supervisor.  Access  to  the  most  privileged  domains  of  the 
system  must  be  characterized  by  a  few,  carefully  defined  entry  points  or 
security  will  reduce  speed  dramatically. 

Input/Output   mediation   can  best   be   handled   by   a  hardware 
architecture  (e.g.,  I/O  processor)  that  allows  direct  user  or  supervisor 
domain  access  to  I/O.   This  requires  the  use  of  a  descriptor  to  control 
access  to  devices  similar  to  the  descriptors  used  for  access  to  memory. 
2.   Uer  i  f  i  cat  i  on 

The  final  comment  about  security  kernel  design  and 
implementation  concerns  verification.  ^/'er  i  f  i  cat  i  on  technology  has  not 
fully  matured  and  is  limiting.  At  the  present  time,  the  greatest  degree 
of  success  has  been  associated  with  specification  verification  such  as 
the  flow  analysis  method  mentioned  earlier  in  Section  B  of  this  chapter. 


30 


III.   POD  TRUSTED  COMPUTER  SYSTEMS  AND  NETUQRKS 

Two  publications  having  possibly  the  greatest  impact  on  multilevel 
security  in  computers  and  distributed  systems  of  computers  or  networks 
are  products  o-f  the  Department  o-f  De-fense  Computer  Center  located  at 
Fort  Meade,  Maryland.  They  are  the  Department  o-f  Defense  Trusted 
Computer  System  Evaluation  Criteria  (CSC-STD-001-83)  dated  15  August 
1983  and  the  Department  of  Defense  Trusted  Network  Evaluation  Criteria 
(currently  in  Draft)  dated  29  July  1985.  These  two  publications  will  be 
discussed  in  some  detail  since  the  blueprint  for  all  acceptable  systems 
must  conform  to  these  criteria  and  the  current  vernacular  of  trusted 
systems  can  be  traced  to  these  documents. 
A.   TRUSTED  COMPUTER  SYSTEMS 

The  publication,  Department  of  Defense  Trusted  Computer  System 
Eva! uat  i  on  Cr  i  ter  i  a  was  written  by  the  Department  of  Defense  Computer 
Security  Center  in  accordance  with  DoD  Directive  5215.1,  "Computer 
Security  Evaluation  Center."  The  purpose  of  document  is  to  establish  a 
"uniform  set  of  basic  requirements  and  evaluation  classes  for  assessing 
the  effectiveness  of  security  controls  built  into  Automatic  Data 
Processing  (ADP)  systems."  [Ref.  6:  p.  i]  Any  ADP  system  used  for  the 
processing  and/or  storage  and  retrieval  of  sensitive  or  classified 
information  by  the  Department  of  Defense  is  to  be  evaluated  using  the 
criteria  defined  in  the  document.  This  publication  is  commonly  referred 
to  as  the  "orange  book." 
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Many  of  the  criteria  presented  in  this  publication  originated  from 
work  done  by  the  MITRE  Corporation  and  the  National  Bureau  of  Standards 
<NBS)  prior  to  the  formation  of  the  DoD  Computer  Security  Center  in 
January  1981.  These  standards  fulfill  two  distinct  sets  of  require- 
ments: 1)  specific  security  feature  requirements;  and  2)  assurance 
requirements.  The  specific  security  features  are  primarily  oriented 
towards  information  systems  employing  general -purpose  operating  systems 
rather  than  applications  programs  being  supported.  The  assurance 
requirements  are  applicable  for  all  computing  environments  ranging  from 
dedicated  controllers  to  full  range  multilevel  secure  resource  sharing 
systems  [Ref  .  6:    p  .2]  . 

1 .   Fundamental  Requirements 

A  secure   computer   system  must   limit  access  to  information  and 

allow  properly  authorized  individuals  or  their  appointed  represenat i ves 

only  to  read,  write,  create,  or  delete  information.   Six  fundamental 

requirements  are  presented  as  absolute  essentials  in  obtaining  such  a 

secure  system.  Four  of  these  requirements  deal  with  the  actual  needs  to 

be   provided   to   control   access   to   information   and   two  deal   with 

assurances  that  this  access  to  information  is  in  fact  being  controlled 

and  that  a  trusted  computer  system  exists. 

The  first   two  requirements   involve  an   organization's  policy 

towards  computer  security: 

Requirement  1  -  Security  Policy 

The  system  must  be  capable  of  enforcing  an  explicit  and 
well-defined  security  policy  to  insure  that  only  personnel  with  proper 
access  (to  include  discretionary  access)  are  allowed  access  to  the 
system.  Security  policy  design  should  be  influenced  by  the  perceived 
threats,  risks  and  goals  of  the  organization. 
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There  are  two  types  o-f  security  policy  to  be  considered: 
mandatory  security  policy  and  discretionary  security  policy.  Mandatory 
security  policy  establishes  a  set  o-f  rules  that  permits  or  denies  access 
to  material  based  directly  on  the  individual's  clearance  or 
authorization.  Discretionary  security  policy  takes  the  permission  or 
denial  o-f  access  one  step  -further  and  is  the  principal  type  o-f  access 
control  available  in  computer  systems  today.  Not  only  must  an 
individual  be  authorized  access  to  i  n-format  i  on ,  but  a  need-to-know 
requirement  must  also  exist.  It  is  important  to  note  that  a 
discretionary  policy  is  to  be  developed  in  addition  to  the  mandatory 
policy  and  not  as  a  substitute. 

Requirement  2  -  Marking 

Objects  must  be  marked  with  access  control  labels  that  con-form 
to  the  mandatory  security  policy.  These  labels  must  identi-fy  the 
sensitivity  or  cl  assi -f  i  cat  i  on  o-f  the  object  and  the  mode  o-f  access  -for 
authorized  users.  Whether  used  internally  or  as  output,  accuracy  and 
integrity  o-f  the  security  labels  is  paramount. 

The  third  and  -fourth  requirements  are  concerned  with 
accountabi 1 i  ty: 

Requirement  3  -  Ident  i-f  icat  i  on 

The  computer  system  must  be  able  to  mediate  access  to 
in-formation  by  identi-fying  authorized  users  and  determining  their  level 
o-f  clearance  and  their  need-to-know.  Once  i  dent  i -f  i  cat  i  on  o-f  the  user 
has  been  established,  there  must  be  a  means  o-f  authentication. 

Requirement  4  -  Accountability 

Audit  in-formation  must  be  recorded  so  that  all  transactions 
a-f-fecting  system  security  can  be  traced  to  the  responsible  party.  This 
in-formation  log  must  be  protected  -from  any  tampering  that  would  alter  or 
delete  such  an  audit  trail. 

The  -final  two  requirements  involve  assurance  that  the  computer 
system  is  secure: 

Requirement  5  -  Assurance 

The  computer  system  must  contain  hardi/iare/so-f tware  mechanisms 
that  can  be  individually  evaluated  to  assure  adherence  to  Requirements 
1-4.  Two  types  o-f  assurance  are  needed:  li-fe-cycle  assurance  and 
operational  assurance. 

"Li-fe-cycle  assurance  re-fers  to  steps  taken  by  an  organization 
to  insure  that  the  system  is  designed,  developed,  and  maintained  using 
-formalized  and  rigorous  controls  and  standards.  .  .Operat  i  onal  assurance 
-focuses  on  -features  and  system  architecture  used  to  insure  that  the 
security  policy  is  unc  i  rcumventabl  y  en-forced  during  system  operation." 
[Re-f.  6:p.  60] 
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Requirement  6  -   Continuous  Protection 

The  computer  system  must  continuously  provide  the  protection 
outlined  in  these  -fundamental  requirements  be-fore  it  can  be  judged  a 
trusted  system. 

2.  The  Cr  i  ter  ia 

The  criteria  set  -forth  by  this  publication  are  divided  into  -four 
hierarchical  divisions:  A:  'Jeri-fied  Protection,  B:  Mandatory  Protection, 
C:  Discretionary  Protection,  and  D:  Minimal  Protection  [Re-f.  6:p.  5]. 
They  are  arranged  -from  the  highest  level  o-f  security  to  the  lowest  level 
respectively.  The  step  up  -from  one  Division  to  another  represents  a 
signi-ficant  increase  in  security.  Divisions  B  and  C  are  -further 
subdivided  into  classes  that  are  arranged  in  a  hierarchical  manner  based 
on  the  security  mechanism  that  they  possess.  A  rating  -for  a  particular 
system  is  based  on  thorough  testing  o-f  the  security-  relevant  portions 
o-f  that  system.  The  security-relevant  portion  o-f  the  system  is  5pol<en 
o-f  collectively  as  the  Trusted  Computing  Base  (TCB)  .  Each  class  is 
described  by  -four  major  sets  o-f  criteria:  Security  Policy, 
Accountability,  Assurance,  and  Documentation. 

Division  D:  Minimal  Protection  has  only  one  class  and  is 
reserved  -for  systems  that  have  been  evaluated,  but  -failed  to  achieve  the 
standards  o-f  a  higher  class. 

Division  C:  Discretionary  Protection  contains  two  classes  that 
provide  discretionary  access  to  in-formation  and  the  means  to  audit  and 
account  -for  such  usage.  The  two  classes  are:  Class  CI:  Discretionary 
Security  Protection  and  Class  C2:  Controlled  Access  Protection. 

The  Trusted  Computing  Base  (TCB)  o-f  Class  CI  satis-fies 
discretionary  access  requirements  by  separating  users  and  data.   The 
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Class  CI  environment  is  expected  to  be  one  o-f  cooperating  users 
processing  data  at  the  same  level  o-f  sensitivity  [Re-f.  6:p.  12]. 
Identification  and  authentication  are  required  to  determine  authorized 
individual  or  group  users. 

The  discretionary  control  o-f  Class  C2  is  made  more  positive 
through  login  procedures,  auditing  o-f  security-relevant  events,  and 
resource  isolation.  The  emphasis  is  on  the  individual  user  in  this 
class.  By  limiting  usage  to  individuals  or  groups  o-f  named  individuals 
accountability  -for  sensitive  data  is  more  easily  maintained. 

Division  B:  Mandatory  Protection  contains  three  classes  that 
are  characterized  by  a  Trusted  Computing  Base  (TCB)  that  preserves  the 
integrity  o-f  the  security  labels  and  uses  them  to  en-force  a  set  o-f 
mandatory  access  control  rules  by  using  the  re-ference  monitor  concept 
(eg.  a  security  kernel).  These  three  classes  are:  Class  Bl  :  Labeled 
Security  Protection,  Class  B2:  Structured  Protection,  and  Class  83: 
Secur  i  ty  Domai  ns.  ,  . 

Class  Bl  systems  have  all  the  same  requirements  -found  in  Class 
C2.  Additionally,  an  in-formal  statement  o-f  the  security  policy  model, 
data  labeling,  and  mandatory  access  control  over  named  subjects  and 
objects  must  be  present.  The  capability  must  exist  -for  accurately 
labeling  exported  in-formation  and  any  -flaws  detected  by  testing  must  be 
corrected  [Re-f .  6:p.  20]  . 

In  contrast  to  Class  Bl  ,  Class  B2  requires  the  presence  o-f  a 
■formal  security  policy  clearly  stating  both  mandatory  and  discretionary 
access  controls.  The  TCB  en-forces  a  more  rigid  authentication 
mechanism.   This  is  the  -first  level  that  addresses  covert  channels  -  a 
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communication  channel  that  allows  the  trans-fer  o-f  in-formation  in  such  a 
manner  that  violates  the  system's  security  policy.  Systems  con-forming 
to  Class  B2  requirements  are  considered  to  be  relatively  resistant  to 
penetrat  i  on . 

Class  B3  must  include  a  re-ference  monitor  that  will  mediate  all 
user  access  to  system  in-formation,  be  tamperproo-f ,  and  be  small  enough 
-for  exhaustive  tests  and  analysis.  Security  administration  is  supported 
and  audit  mechanisms  are  expanded  to  signal  all  security-relevant  events 
with  recovery  procedures  required.  Class  B3  systems  are  considered  to 
be  highly  resistant  to  penetration. 

Finally,  Division  A:  ^^eri-fied  Design  presently  contains  one 
class  -  Class  Al :  'vieri-fied  Design  which  has  the  most  rigid  security 
requirements  given  the  state  o-f  current  technology.  Extensive 
documentation  is  required  on  the  TCB  to  demonstrate  the  ability  to 
con-form  to  security  requirements.  Systems  in  this  class  are 
■functionally  equivalent  to  Class  B3.  There  are  no  architectural 
features  or  policy  di -f-ference .  The  signi-ficant  highlight  is  the  added 
emphasis  on  -formality  in  this  class.  Formal  security  ver  i -f  i  cat  i  on 
methods  are  required  to  assure  that  both  mandatory  and  discretionary 
access  controls  protect  all  classi-fied  or  sensitive  in-formation  either 
stored  or  processed  on  the  trusted  system. 

Figure  3.1  [Re-f.  6:p.  107]  summarizes  the  trusted  computer 
system  evaluation  criteria  requirements  -for  each  cl  assi -f  i  cat  i  on  . 
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B.   TRUSTED  NETWORK  SYSTEMS 

The  second  DoD  Computer   Security  Center  publication   previously 
mentioned  currently  exists   in  dra-ft   -form  only.    The  document   is 
entitled,  Department  o-f  De-fense  Trusted  Network  Evaluation  Criteria, 
dated  29  July  1985,  and  is  the  logical  complement  to  the  DoD  Trusted 
Computer  System  Evaluation  Criteria. 

The  criteria  were  -first  established  -for  computer  systems  in  1983, 
but  it  was  soon  realized  that  there  were  unique  risks  associated  with 
distributed  systems  or  networks  that  needed  to  be  addressed  separately. 

Distributed  computer  systems  or  networks  are  composed  o-f  a  set  o-f 
nodes,  communications  lines  connecting  these  nodes,  and  a  set  of  rules 
(protocol)  to  facilitate  the  network's  operation.  A  node  is  usually 
composed  of  a  communications  processor  (switch)  and  at  least  one  host 
processor.  At  one  extreme,  a  single  processor  may  serve  both  the 
communications  and  host  functions.  On  the  other,  each  function  may  be 
performed  by  multiprocessors.  A  typical  node  configuration  may  include 
a  communications  processor,  a  host,  and  a  network  front-end  processor 
(NFEP)  which  may  perform  both  pre-  and  post-  processing  for  the  host. 

Establishing  a  security  policy  for  a  distributed  system  is  a  far 
greater  task  than  in  a  centralized  system.  Security  in  the  distributed 
system  is  only  as  strong  as  the  quality  of  the  enforced  security  policy 
at  any  one  node  and  a  breach  of  security  at  one  node  can  have  grave 
implications  for  other  nodes  in  the  system.  An  environment  exists  where 
users  interact  with  host  systems  via  remote  access  terminals  in  a  real 
time  fashion  where  data  can  be  accessed,  read,  altered,  or  destroyed  in 
a  very  rapid  manner.   Often  these  remote  terminals  are  in  a  more  hostile 
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environment  than  the  host  and  the  user  is  -free  -from  administrative  and 
operational  controls. 

Certainly,  the  security  issues  o-f  distributed  systems  are  more  than 
the  union  o-f  the  security  issues  o-f  communications  and  computer  systems. 
These  issues  address  a  unique  threat  o-f  leakage  or  loss  CRe-f.  8:p.  301: 

1.  The  physical  security  problem  extends  beyond  the  physical 
environs  o-f  host  computer's  location. 

2.  The  communications  lines  are  vulnerable  to  tapping  or 
passive  monitoring  o-f  emanations.  Crosstall<  between 
communications  lines  or  within  the  switching  centrals  can 
present  a  vulnerability. 

3.  A  large  population  o-f  users  with  varying  clearances  and 
need-to-know  authorizations  interact  simultaneously  on  the 
network  system. 

4.  The  probability  o-f  system  error  and  vulnerability  to 
intrusion  becomes  greater  as  the  size  o-f  the  network 
increases. 

5.  Exhaustive  testing  and  ver  i -f  i  cat  i  on  o-f  so-ftware  to  determine 
i -f  errors  or  anomalies  exist  is  not  possible  -for  large 
so-ftware  systems. 

6.  The  i  dent  i -f  i  cat  i  on  o-f  a  user  located  at  a  remote  terminal  or 
■facility  is  more  di-f-ficult. 

The  Trusted  Network  Evaluation  Criteria  is  divided  into  two  parts: 
Trusted  Network  Criteria,  applied  on  a  global  network-wide  basis,  and 
Trusted  Network  Component  Criteria,  applicable  to  individual  network 
components.  Both  parts  are  closely  linked  and  many  o-f  the  criteria  are 
derived  -from  the  "orange  book." 

Again,  there  are  -four  hierarchical  divisions  o-f  enhanced  security 
protection.  These  divisions  are  delineated  with  respect  to  the  three 
issues  o-f  data  compromise,  erroneous  communications,  and  denial  o-f 
service.   Since  di-f-ferent  hardware  and  so-ftware  are  likely  to  be  used 
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within  network  systems,  a  separate  evaluation  should  be  conducted  in 
each  area. 

For  a  network  to  be  assigned  a  division  rating  -for  data 
compromise,  erroneous  communications,  or  denial  o-f  service  the  network 
must  satis-fy  all  Trusted  Network  Criteria  -for  that  division  and  all  o-f 
its  trusted  components  must  satis-fy  at  least  the  equivalent  division 
requirements  o-f  the  Trusted  Network  Component  Criteria.  Limited  by 
technology,  criteria  -for  erroneous  communications  and  denial  o-f  service 
are  yet  to  be  de-fined  -for  the  most  rigid  security  division,  NA. 

A  re-ference  model  such  as  the  International  Standards  Organization 
Open  Systems  Interconnection  (OSI)  Model  or  its  equivalent  must  be 
established  -for  comparison  purposes  when  evaluating  a  network.  "The 
hierarchy  o-f  protocols  to  be  used  within  the  network  by  host  computers 
and  network  components  must  be  speci-fied,  as  well  as  the  location  and 
content  o-f  any  security-relevant  in-formation  contained  within  those 
protocols,  such  as  security  labels.  A  direct  correspondence  must  be 
shown  between  the  security-relevant  portions  o-f  these  communications 
protocols  and  the  security  -features  employed  in  the  trusted  components." 
[Re-f.  7:p.  4] 

1 .   Fundamental  Requirements 

The  six  -fundamental  requirements  listed  previously  -for  a 
"secure"  computer  system  can  be  extended  -for  applicability  to  the 
"secure"  network  with  little  modi -f  i  cat  i  on  -  -four  dealing  with  what  needs 
to  be  done  to  control  security  in  a  trusted  network  and  two  dealing  with 
credible  assurances  that  these  requirements  are  met. 


40 


2.  The  Criteria 

Again,  the  Trusted  Network  Criteria  de^fine  the  minimum  set  o-f 
global  security  -features  and  assurance  requirements  to  be  met  by  the 
Trusted  Network  Base  <TNB)  .  There  are  many  parallels  between  the  -four 
hierarchical  divisions  o-f  the  Trusted  Network  Criteria  and  the  Trusted 
Computer  Systems  Evaluation  Criteria.  The  -four  divisions  are  Division 
ND,  Division  NC,  Division  NB,  and  Division  NA.  Signi-ficant  additions 
having  relevancy  to  trusted  network  systems  will  be  discussed. 

Division  ND:  Minimal  Protection  is  reserved  -for  those  systems 
that  have  been  evaluated  but  -failed  to  meet  the  requirements  -for  a 
higher  evaluation  division.  Minimum  security  results  and  there  are  no 
security  -features  to  protect  against  data  compromise,  erroneous 
communications,  and  denial  o-f  service. 

Minimal  data  compromise,  erroneous  communication;,  and  de.nial  of 
service  are  indicative  o-f  Division  NC:  Controlled  Access  Protection. 
Security  decisions  based  on  the  cl  assi -f  i  cat  i  on  o-f  in-formation  are 
handled  administratively;  thus,  networks  within  this  division  are  not 
required  to  make  security  decisions  based  on  the  cl  assi -f  i  cat  i  on  o-f 
objects  and  subjects.  Network  compromise  protection  is  achieved  through 
the  use  o-f  techniques  such  as  resource  isolation  within  network 
components,  data  encryption,  or  physical  protection  o-f  the 
communications  medium.  Network  discretionary  access  control  is  de-fined 
by  the  Trusted  Network  Base  (TNB)  and  uses  en-forcement  mechanisms  such 
as  closed  user  groups  and  network  access  control  lists  to  include  or 
exclude  access  with  the  -focus  on  the  single  network  subject.  The 
-following  documentation  is  also  required  -for  this  division:  Network 
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Security  Features  User's  Guide,  Trusted  Network  Facility  Manual,  Network 
Test  Documentation,  and  Network  Design  Documentation. 

A  documented,  -formal  security  policy  model  that  requires 
mandatory  access  control  en-forcement  over  all  network  subjects  and 
network  objects  and  which  addresses  the  issue  o-f  covert  channels  must 
exist  -for  networks  within  Division  B:  Mandatory  Protection.  TNB  design 
and  implementation  require  more  thorough  testing  and  more  complete 
review.  The  TNB  must  maintain  sensitivity  labels  -for  all  network 
resources  that  can  be  accessed  either  directly  or  indirectly  by  subjects 
external  to  the  TNB.  These  labels  are  to  be  used  as  the  basis  -for 
access  control  decisions.  "The  TNB  shall  support  a  trusted 
communication  path  between  network  subjects  -for  use  when  positive 
component  to  component  communication  is  required  (e.g.,  initialization, 
encryption  key  management,  change  o-f  network  subject  security  level(s)). 
Communications  via  this  trusted  path  shall  be  activated  exclusively  by  a 
network  subject  or  the  TNB  and  shall  be  logically  and  unmistakably 
distinguishable  -from  other  paths."  [Re-f.  7:p.  19]  The  same  documents 
are  required  as  in  the  previous  level;  however,  a  more  -formal 
description  o-f  the  network^'s  resources  and  test  results  is  needed. 

Division  NA:  ^eri-fied  Design  requires  networks  to  possess  a 
re-ference  monitor  that  mediates  all  accesses  o-f  subjects  to  objects,  be 
tamperproo-f ,  and  the  distributed  portions  o-f  the  TNB  to  be  small  enough 
to  be  subjected  to  analysis  and  tests.  Formal  design  spec  i -f  i  cat  i  on  and 
ver  i -f  i  cat  i  on  techniques  assure  that  the  TNB  is  correctly  implemented. 
There  are  two  types  o-f  -formal  spec  i -f  i  cat  i  on  -  "-formal  policy  model"  and 
"-formal  top  level  spec  i -f  i  cat  i  on  (FTLS)".   The  "-formal  policy  model"  is 
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used  to  analyze  a  complete  network  and  must  be  demonstrated  by  a 
mathematical  proo-f  that  it  supports  the  security  policy.  The  "formal 
top  level  specification  (FTLS)"  deals  with  the  detailed  -functionality  o-f 
the  network  and  must  be  consistent  with  the  model  by  -formal  yer  i -f  i  cat  i  on 
techniques.  Formal  analysis  techniques  must  be  used  to  identi-fy  and 
analyze  covert  channels. 

The  Trusted  Network  Component  Criteria  are  detailed  to  establish 
the  minimum  set  o-f  security  -features  and  assurance  requirements  that 
each  component  must  meet  in  order  to  insure  that  the  global  Trusted 
Network  Base  (TNB)  requirements  can  be  achieved.  These  standards  are 
treated  in  the  same  manner  as  the  a-forement  i  oned  Trusted  Network 
Criteria;  thus,  little  purpose  is  served  by  pointing  out  the  specific 
requirements  of  each  division  (see  Reference  7  for  more  details). 
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lU.   RISK  ASSESSMENT 

The  purpose  o-f  multileyel  security  is  to  provide  cost-e  +  -fect  i  ve 
countermeasures  to  protect  a  system  -from  the  many  threats  which  exist. 
These  countermeasures  must  reduce  the  frequency  and  impact  o-f  threats 
upon  the  system,  provide  -for  contingency  planning  when  the  system  s 
operation  is  disrupted,  and  audit  the  system  in  both  the  normal  and 
standby  modes  o-f  operation.  The  problem  o-f  weighing  the  risk  o-f  the 
loss  threatened  with  the  cost  o-f  e-f-fective  countermeasures  gives  rise  to 
the  imprecise  science  o-f  risk  management.  A  brie-f  discussion  o-f  risk 
management  in  general  will  be  -followed  by  a  look  at  the  methodology  set 
-forth  by  the  DoD  Computer  Security  Center  -for  assessing  a  system's 
inherent  risk  and  at  an  approach  suggested  by  Carl  Landwehr  and  H.  0. 
Lubbes  o-f  the  Naval  Research  Laboratory  in  Uashington,  D.C. 
A.   RISK  MANAGEMENT 

Risk  management  involves  the  manipulation  o-f  various  tools  and 
techniques  tailored  to  meet  a  speci-fic  need  in  the  prevention  o-f 
unauthorized  intervention  in  the  various  levels  o-f  a  system  s  operation. 
However,  the  methodologies  employed  are  basic  [Re-f.  9:p.  261: 

a.  Threat  i  dent  i -f  i  cat  i  on 

b.  Threat  impact  measurement 

c.  Coun  termeasure  i  dent  i -f  i  cat  i  on  and  measurement 

d.  Countermeasure  selection 

e.  Implementation  and  monitoring  o-f  sa-feguard  e-f-fect 
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Historically,  risk  managers  have  measured  the  cost-e-f-fec  t  i  yeness  oi 
security  measures  taken  in  terms  o-f  dollars.  This  has  led  to  greater 
concern  oyer  those  threats  that  cause  total  or  near  total  destruction  o-f 
the  system  (e.g.,  natural  causes,  gross  errors,  omissions).  H 
reasonable  security  measures  have  been  taken,  many  o-f  these  threats 
<e.g.,  errors  and  omissions)  have  a  greater  probability  o-f  occurrence 
than  penetration  o-f  the  system  by  an  unauthorized  source  .  It  is  also 
di-f-ficult  to  determine  the  "cost"  o-f  compromised  classi-fied  in-formation 
(assuming  that  a  penetration  has  been  detected).  However,  once  the 
commitment  is  made  to  develop  multilevel  trusted  systems,  greater  access 
to  systems  by  users  o-f  varying  levels  o-f  clearances  and  need-to-know 
authorizations  increase  the  risk  o-f  compromise.  The  need  still  exists 
•for  sa-feguards  against  the  traditional  concerns,  but  the  threat  o-f 
unauthorized  penetration  must  be  given  much  greater  attention  when  the 
secrets  o-f  a  nation  are  at  stake.  The  DoD  Computer  Security  Center  has 
developed  a  scheme  -for  assessing  the  risk  in  trusted  systems. 
B.  RISK  INDEX 

The  evaluation  classes  described  in  the  DoD  Trusted  Computer  System 
Eval  uat  i  on  Cr  i  ter  i  a  are  primarily  based  on  the  level  o-f  security  risk 
inherent  to  a  particular  system.  Another  DoD  Computer  Security  Center 
publication.  Technical  Rationale  Behind  CSC-STD-QQ3-35;  Computer 
Security  Requirements — Guidance  -for  Applying  the  Department  o-f  De-fense 
Trusted  Computer  System  Evaluation  Criteria  in  Specific  Environments, 
presents  a  methodology  -for  assessing  a  system's  inherent  risk  -  the 
"risk  index."  "The  risk  index  can  be  de-fined  as  the  disparity  between 
the  minimum  clearance  or  authorization  o-f  system  users  and  the  maximum 
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sensitivity  o-f  data  processed  by  a  system."  [Re-f.  10:p.  5]  Although 
other  -factors  can  in-fluence  security  risk,  the  risk  index  is  uni+ormly 
applied  in  the  determination  o-f  security  risk  and  is  the  only  basis  -for 
determining  the  minimum  class  o-f  trusted  systems. 

The  risk   index  is   computed   by  comparing  the  system's  minimum  user 

clearance  <Rn,in)  -from  Table  4.1  CRe-f.  10:p.  61   with  the  system's  maximum 

data   sensitivity   (R^ax^  ^^°^      Table   4.2   [Re-f.   10:p.   73.     The 

relationships  -for  the  actual  computations  -follow: 

Case  I.   I-f   Rnjjn   '^   less   than   R^ax  ^^^^      the   Risk   Index   is 

determined  by  subtracting  Rf^j^  ^^om   R^jax ' 

Risk  Index  =  R^^,  -  R^^^ 

(This  equation  works  in  all   cases  but  one.    When  the 

minimum  clearance  is  Top  Secret/Background  Investigation 

and  the  maximum  data  sensitivity  is  Top  Secret,  the  Risk 

Index  should  be  0  rather  that  the  computed  value  o-f  1.) 

Case  II.   I-f  Rfj^jn  is  greater  than  or  equal  to  R^ax  i  then: 

I  1  ,  i -f  there  are  categories  on  the  system 
Risk  Index  =        I     to  which  some  o-f  the  users  are  not 

I     authorized  access. 

I  2,  otherwise  (i.e.,  i-f  there  are  no 
Risk  Index  =        I     categories  on  the  system  or  i-f  all 

I     users  are  authorized  access  to  all 
I     categor i es) . 

Table  4.3  [Re-f.  10:p.  8]   is  a  matrix   o-f   computed   security   risk 

indexes  -for  categories  associated  with  maximum  data  sensitivity  levels 

above   Secret.   I-f   local   authorities  -feel   that   the   environment   has 

additional  risk  factors  a-f-fecting  system  security,  a  larger  risk  index 

can  be  assigned. 
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TABLE    4.1 
RATING  scalp:  FOR  MINIMUM  USER  CLEARANCEi 


MINIMUM  USER  CLEARANCE    ' 

RATING 
(Rmin) 

Uncleared  (U) 

0 

Not  Cleared  but  Authorized  Access  to  Sensitive  Unclassified 

Information  (N) 

1 

Confidential  (C) 

2 

Secret (S) 

3 

Top  Secret  iTSVCurrent  Background  Investigation  (BI) 

4 

Top  Secret  (TS)/Carrent  Special  Background  Investigation  (SBI) 

5 

One  Category  (IC) 

6 

Multiple  Categories  (MC) 

/ 

iSee  Apppendix  B  for  a  detailed  description  of  the  terms  listed 
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TABLE    4.2 


RATING  SCALE  FOR  MAXIMUM  DATA  SENSITIVITY 


MAXIMUM  DATA 

SENSITIVITY 

RATINGS' 

RATING 

MAXIMUM  DATA  SENSITIVITY  WITH 

WITHOUT 

(Rmax) 

CATEGORIES! 

CATEGORIES 

(Rmax) 

Unclassified  (U) 

0 

Not  Applicable^ 

Not  Classified  but 

I 

N    With  One  or  More  Categories 

2 

Sensitive'* 

• 

Contldentul  iC) 

2 

C     With  One  or  More  Categories 

3 

Secret iS) 

3 

S     With  One  or  More  Categories  With  No 
More  Than  One  Category  Containing 
Secret  Data 

4 

S    With  Two  or  More  Categories  Containing 

5 

Secret  Data 

Top  Secret  (TS) 
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TS     With  One  or  More  Categories  With  No 
More  Than  One  Category  Containing 
Secret  or  Top  Secret  Data 

6 

TS     With  Two  or  More  Categories 
Containing  Secret  or  Top  Secret  Data 

7 

iThe  only  categories  of  concern  are  those  for  which  some  users  are  not  authorized  access  to  the 
category    When  counting  the  number  of  categories,  count  all  categories  regardless  of  the 
sensitivity  level  associated  with  the  data.  If  a  category  is  associated  with  more  than  one 
sensitivity  level,  it  is  only  counted  at   the  highest  level. 

2Where  the  number  of  categories  is  large  or  where  a  highly  sensitive  category  is  involved,  a 
higner  rating  might  be  warranted. 

^Since  categories  imply  sensitivity  of  data  and  unclassified  data  is  not  sensitive,  unclassified 
data  by  definition  cannot  contain  categories. 

*N  data  includes  financial,  proprietary,  privacy,  and  mission  sensitive  data.  Some  situations 
(eg,  those  involving  extremely  large  financial  sums  or  critical  mission  sensitive  data),  may 
warrant  a  higher  rating    The  table  prescribes  minimum  ratings 

5The  rating  increment  between  the  Secret  and  Top  Secret  data  sensitivity  levels  is  greater  than 
the  increment  between  other  aajacent  levels.  This  ditlerence  derives  from  the  fact  that  the  loss 
of  Top  Secret  data  causes  exceptionally  '.^rave  damage  to  the  national  security,  whereas  the  loss 
of  Secret  data  causes  only  serious  aamage.l4) 
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Minimum 

Clearance 

or 

Authorization 

of 

System  Users 


TABLE    4.3 
SECURITY  RISK  INDEX  MATRIX 

Maximum  Data  Sensitivity 


u 

N 

C 

s 

TS 

IC 

MC 

u 

0 

1 

2 

3 

5 

6 

7 

N 

0 

0 

1 

2 

4 

5 

6 

C 

0 

0 

0 

1 

3 

4 

5 

s 

0 

0 

0 

0 

2 

3 

4 

TS(BI) 

.  0 

0 

0 

0 

0 

2 

3 

TS(SBI) 

0 

0 

0 

0 

0 

1 

2 

IC 

0 

0 

0 

0 

0 

0 

1 

MC 

0 

0 

0 

0 

0 

0 

0 

U  =  Uncleared  or  Unclassified 

N  =  Not  Cleared  but  Authorized  Access  to  Sensitive  Unclassified  Information  or 

Not  Classified  but  Sensitive 

C  =  Confidential 

S  =  Secret 

TS  =  Top  Secret 

TS(BI)  =  Top  Secret  (Background  Investigation) 

TS(SBI)  =  Top  Secret  (Special  Background  Investigation) 

IC  =  One  Category 

MC  =  Multiple  Categories 
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C.   SECURIP('  ENVIRONMENT 

As  mentioned  previously,  -factors  other  than  the  risk  index  are 
important  when  the  overall  threat  o-f  compromised  in-formation  is  to  be 
considered.  One  such  -factor  is  the  nature  o-f  the  environment  in  which 
the  system  is  operating.  The  environment  is  the  aggregate  o-f  external 
-factors  a-f-fecting  the  development,  operation,  and  maintenance  o-f  a 
system.  Two  common  environments  re-ferred  to  are  the  open  and  the  closed 
environment.  This  description  is  based  upon  the  TCB's  vulnerability  to 
the  insertion  of  malicious  logic.  Malicious  logic  can  be  either 
hardware,  so-ftware,  or  -firmware  that  is  intentionally  included  in  a 
system  -for  the  express  purpose  o-f  causing  loss  or  harm.  An  open 
environment  is  one  in  which  adequate  precautions  against  the  insertion 
o-f  malicious  logic  have  not  been  invoked.  Conversely,  a  closed 
environment  is  one  that  is  considered  to  be  adequately  protected  against 
such  threats. 

1  .   Open  Security  Environment 

An  open  security  environment  exists  when  either  o-f  the  -following 
conditions  holds  true: 

a.  Application  developers  (including  maintainers)  do  not  have 
su-f-ftcient  clearance  (or  authorization)  to  provide  an 
acceptable  presumption  that  they  have  not  introduced 
malicious  logic.  Su-f-ficient  clearance  is  de-fined  as 
-follows:  where  the  maximum  c1  assi -f  i  cat  i  on  o-f  data  to  be 
processed  is  Con-f  i  dent  i  al  or  below,  developers  are  cleared 
and  authorized  to  the  same  level  as  the  most  sensitive  data; 
where  the  maximum  cl  assi -f  i  cat  i  on  o-f  data  to  be  processed  is 
Secret  or  above,  developers  have  at  least  a  Secret 
cl earance  . 

b.  Con-figuration  control  does  not  provide  su-f-ficient  assurance 
that  applications  are  protected  against  the  introduction  o-f 
malicious  logic  prior  to  or  during  the  operation  o-f  system 
applications.  [Re-f.  10:p.  31] 


50 


In  the  open  security  environment,  the  application  o-f  malicious 
logic  can  a-f-fect  the  TCB  in  two  ways.  The  -first  way  is  an  attack  on  TCB 
controls  in  an  attempt  to  "penetrate"  the  system.  Secondly,  any  couert 
channels  that  exist  in  the  TCB  can  be  exploited. 

Table  4.4  presents  the  minimum  evaluation  class  identified  in 
the  Computer  Security  Requirements  -for  di-f-ferent  risk  indices  in  an  open 
security  environment  CRet.  10:p.  123.  Table  4.5  illustrates  the  impact 
o-f  the  requirements  on  individual  minimum  clearance/maximum  data 
sensitivity  pairings,  where  no  categories  are  associated  with  maximum 
data  sensitivity  below  Top  Secret  [Re-f.  10:p.  13].  The  classes  obtained 
-from  these  tables  re-flect  minimum  values.  Again,  i -f  the  environment 
dictates,  the  assignment  o-f  a  higher  class  may  be  warranted.  Two 
-factors  that  may  lead  to  a  higher  class  assignment  are:  a)  High  volume 
o-f  i  a-format  i  on  at  the  maximum  data  sensitivity,  and  b.)  Large  numbers  o-f 
users  with  minimum  clearance.   These  two  -factors  are  common  in  networks. 

Systems  operating  in  a  system  high  or  dedicated  mode  have  a  r i sk 
index  o-f  zero.  A  system  operating  in  the  dedicated  mode  is 
characterized  by  all  users  having  the  appropriate  clearance  and 
need-to-know  requirements  -for  all  in-formation  on  the  system.  Strictly 
speaking,  no  additional  requirements  exist  -for  hardware  or  so-ftware  to 
en-force  the  security  policy;  however,  such  -features  may  be  necessary 
because  o-f  the  integrity  and  denial  o-f  service  requirements  -for  many 
systems. 

A  system  operating  in  the  system  high  mode,  is  characterized  by 
all  users  having  the  appropriate  clearance  but  not  the  need-to-know  -for 
all  i  n -forma  1 1  on  on  the  system.   Obviously,  discretionary  measures  are 
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TABLE    4.4 

COMPUTER  SECURITY  REQUIREMENTS  FOR  OPEN  SECURITY 

ENVIRONMENTS 


RISK  INDEX 

SECURITY  OPERATING 
MODE 

\nNi:.IUM  CRITERLA 
CLASSi 

0 

Dedicated 

No  Prescribed 
Minimum2 

0 

System  High 

C2:i 

1 

Limited  Access.  Controlled, 
Compartmented.  Multilevel 

B14 

Limited  Access.  Controlled, 
Compartmented,  Multilevel 

B2 

3 

Controlled,  Multilevel 

B3 

4 

Multilevel 

Al 

5 

Multilevel 

« 

6 

Multilevel 

* 

7 

Multilevel 

« 

iThe  asterisk  (*)  indicates  that  computer  protection  for  environments  with  that 
risk  index  are  considered  to  be  beyond  the  state  of  current  technology.  Such 
environments  must  augment  technical  protection  with  personnel  or 
administrative  security  safeguards. 

2Although  there  is  no  prescribed  minimum,  the  integrity  and  denial  of  service 
requirements  of  many  systems  warrant  at  least  class  Cl  protection. 

3If  the  system  processes  sensitive  or  classified  data,  at  least  a  class  C2  system  is 
required.  If  the  system  does  not  process  sensitive  or  classified  data,  a  class  Cl 
system  is  sufficient. 

•iWhere  a  system  processes  classified  or  compartmented  data  and  some  users  do  not 
have  at  least  a  Confidential  clearance,  or  when  there  are  more  than  two  types  of 
compartmented  information  being  processed,  at  least  a  class  B2  system  is  required. 
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TABLE    4.5 
SECURITY  INDEX  MATRIX  FOR  OPEN  SECURITY  ENVIRONMENTS! 


Max 

:imum 

DataS 

Sensitivity 

U 

N 

C 

S 

TS 

IC 

MC 

U 

CI 

BI 

B2 

B3 

« 

* 

* 

Minimum 

N 

CI 

C2 

B2 

B2 

Al 

« 

* 

Clearance  or 
Author- 

C • 

CI 

C2 

C2 

Bl 

B3 

Al 

* 

ization 
of  System 
Users 

s 

CI 

C2 

C2 

C2 

B2 

B3 

Al 

TS{BI) 

CI 

C2  . 

C2 

C2 

C2 

B2 

B3 

TS(SBI) 

CI 

C2 

C2 

C2 

C2 

Bl 

B2 

IC 

CI 

C2 

C2 

C2 

C2 

C2'.^ 

B13 

MC 

CI 

C2 

C2 

C2 

C2 

po2 

C22 

lEnvironments  for  which  either  Cl  or  C2  is  given  are  for  systems  that  operate  in 
system  high  mode.  No  minimum  level  of  trust  is  prescribed  for  systems  that 
operate  in  dedicated  mode.    Categories  are  ignored  in  the  matri.x,  e.xcept  for  their 
inclusion  at  the  TS  level.  i  . 

2It  is  assumed  that  all  users  are  authorized  access  to  all  categories  present  in  the 
system.  If  some  users  are  not  authorized  for  all  categories,  then  a  class  Bl  system 
or  higher  is  required. 

SWhere  there  are  more  than  two  categories,  at  least  a  class  B2  system  is  required. 

U  =  Uncleared  or  Unclassified 

N  =  Not  Cleared  but  Authorized  Access  to  Sensitive  Unclassified  Information  or 

Not  Classified  but  Sensitive 

C  =  Confidential 

S  =  Secret 

TS  =  Top  Secret 

TS(BI)  =  Top  Secret  (Background  Investigation) 

TS(SBI)  =  Top  Secret(Special  Background  Investigation) 

IC  =  One  Category 

MC  =  Multiple  Category 
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needed  to  protect  in-formation  -from  those  users  without  the  appropriate 
need-to-know.  At  least  a  Class  C2  system  is  required  because  o-f  its 
accountability  capabilities  when  systems  process  and/''or  store  classi-fied 
or  sensitive  unci  assi -f  i  ed  data.  H  the  maximum  sensitivity  o-f  the  data 
is  unci  assi -f  i  ed,  a  Class  CI  system  is  acceptable.  No  audit  trails  are 
traceable  to  the  individual,  but  protection  is  still  needed  to  protect 
project  or  private  in-formation  and  to  prevent  the  accidental  reading  or 
destruction  o-f  another  user's  data. 

A  risk  index  o-f  1  or  higher  is  characteristic  o+'  systems 
operating  in  controlled,  compartmented,  and  multilevel  modes.  In  these 
modes,  mandatory  access  control  to  objects  is  usually  controlled  by  the 
use  o-f  sensitivity  labels.  Mandatory  access  controls  are  inherent  to 
Division  A  and  B  systems  and  are  required  -for  all  environments  with  risk 
indices  o-f  1  or  greater.  The  minimum  class  recommended  -for  systems 
requiring  mandatory  access  control  is  Class  Bl . 

Systems  with  a  risk  index  o-f  2  require  more  trust  than  is 
a-f-forded  by  the  Class  Bl  system.  Where  a  sensitivity  label  alone  exists 
(no  label  denoting  category),  Class  B2  systems  are  the  minimum 
requirement  -for  minimum  clearance/maximum  data  sensitivity  pairings 
such  as  U/C,  N/S,  and  S/TS. 

Although  Class  B2  systems  are  relatively  resistant  to 
penetration,  a  risk  index  o-f  3  requires  even  greater  resistance  to 
penetration  such  as  that  demonstrated  by  a  Class  83  system.  Class  B3 
systems  are  the  minimum  requirement  -for  minimum  clearance/maximum  data 
sensitivity  pairings  o-f  U/S,  C/TS,  S/TS  with  one  category  and  TS(BI)/TS 
with  multiple  categories. 
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The  most  trustworthy  systems  at  the  present  time  are  Class  Al 
systems.  Class  Al  systems  are  to  be  used  -for  situations  with  a  risk 
index  of  4  and  are  the  minimum  requirement  -for  minimum  clearance/maximum 
data  sensitivity  pairings  o-f  N/TS,  C/TS  with  one  category,  and  S/TS  with 
multiple  categories.  Formal  design  specification  and  yer  i -f  i  cat  i  on 
techniques  distinguish  Class  Al  from  Class  B3  (the  architecture  and 
policy  requirements  are  the  same). 

Any  system  operating  in  an  environment  with  a  risk  index  of  5  or 
greater  cannot  be  made  trustworthy  with  current  technology.  An  open 
environment  with  uncleared  users  and  Top  Secret  data  is  not  permissible 
under  any  conditions. 

2.   Closed  Security  Environment 

A  closed  security  environment  is  protected  from  the  insertion  of 
malicious  logic;  however,  a  threat  to  the  TCB  exists  from  the 
exploitation  of  unintentional  errors  in  logic  for  malicious  purposes.  A 
closed  security  environment  exists  when  both  of  the  following  conditions 
hold  true: 

a.  Applications  developers  (including  maintainers)  have 
sufficient  clearances  and  authorizations  to  provide  an 
acceptable  presumption  that  they  have  not  introduced 
mal i  c  i  ous  1 ogi  c . 

b.  Configuration  control  provides  sufficient  assurance  that 
applications  are  protected  against  the  introduction  of 
malicious  logic  prior  to  and  during  the  operation  of  system 
applications.  [Ref.  10:p.  32] 

Clearances   are   required  for   assurance   against  malicious 

applications  logic  because  there  are  relatively  few  tools  for  assessing 

the  security-relevant  behavior  of  application  hardware  and  software. 

The   DoD   Computer   System   Evaluation   Criteria   outline  assurance 
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requirements  such  as  extensive  -functional  testing,  penetration  testing, 
and  correspondence  mapping  between  a  security  model  and  the  design  -for 
increased  confidence  in  the  TCB . 

In  the  closed  security  environment,  a  Class  B2  system  is  the 
result  o-f  adherence  to  requirements  that  are  rigid  enough  to 
substantially  reduce  the  number  o-f  unintentional  errors  in  logic  and  is 
worthy  o-f  increased  trust.  A  system  evaluated  as  a  Class  Bl  system  in 
an  open  security  environment  cannot  be  degraded  to  a  Class  CI  or  C2 
system  in  a  closed  security  environment  because  o-f  the  requirement  -for 
mandatory  access  controls. 

Table  4.6  presents  the  minimum  evaluation  class  identi-fied  in 
the  Computer  Security  Requirements  -for  di-f-ferent  risk  indices  in  a 
closed  security  environment  [Re-f.  10:p.  203.  The  principal  di -f-fe.rence 
between  the  open  and  closed  security  environments  is  that  Class  82 
systems  in  the  closed  security  environment  are  trusted  to  provide 
su-f-ficient  protection  -for  a  greater  risk  index.  Table  4.7  illustrates 
the  requirement's  impact  on  individual  minimum  clearance/maximum  data 
sensitivity  pairings  [Re-f.  10:p.  21].  Unlike  the  open  security 
environment,  protection  support  -for  some  closed  environments,  such  as  an 
uncleared  user  on  a  system  processing  Top  Secret  data,  is  allowed. 
D.   ANOTHER  APPROACH  FOR  RISK  ASSESSMENT 

Carl  Landwehr  and  H.  0.  Lubbes  -feel  that  the  DoD  Computer  Security 
Center  did  an  outstanding  job  o-f  de-fining  requirements  corresponding  to 
speci-fied  levels  o-f  security  -functions  and  assurance.  However,  the 
technical  guidance  provided  -falls  short  o-f  adequately  providing  guidance 
-for  what  level  o-f  system  is  appropriate  in  a  given  environment.   They 
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TABLE    4.6 

COMPUTER  SECURITY  REQUIREMENTS  FOR  CLOSED  SECURITY 

ENVIRONMENTS 


RISK  INDEX 

SECURITY  OPERATING 
MODE 

^^NIMUM  CRITERIA 
CLASSi 

0 

Dedicated 

No  Prescribed 
Minimum- 

0 

System  High 

C23 

1 

Limited  Access,  Controlled, 
Compartmented.  Multilevel 

BH 

2 

Limited  Access,  Controlled, 
Compartmented.  Multilevel 

B2 

3 

Controlled.  Multilevel 

B2 

4 

Multilevel 

B3 

5 

Multilevel 

AI 

6 

Multilevel 

« 

7 

Multilevel 

* 

IThe  asterisk  (*)  indicates  that  computer  protection  for  environments  with  that 
risk  mdex  are  considered  to  be  beyond  the  state  of  current  technolo^.  Such 
environments  must  augment  technical  protection  with  physical,  personnel, 
and/or  administrative  safeguards. 

2Althcugh  there  is  no  prescribed  minimum,  the  integrity  and  denial  of  service 
requirements  of  many  systems  warrant  at  least  class  C 1  protection. 

3If  the  system  processes  sensitive  or  classified  data,  at  least  a  class  C2  system  is 
required.  If  the  system  does  not  process  sensitive  or  classified  data,  a  class  Cl 
system  is  sufficient. 

■iWhere  a  system  processes  classified  or  compartmented  data  and  some  users  do 
not  have  at  least  a  Confidential  clearance,  at  least  a  class  B2  system  is  required. 


57 


TABLE    4.7 
SECURITY  INDEX  MATRIX  FOR  CLOSED  SECURITY  ENVIRONMENTS! 


Minimum 
Clearance  or 
Author- 
ization 
of  System 
Users 


Maximum 

DataS 

Jensiti' 

i/ity 

U 

N 

C 

S 

TS 

IC 

MC 

u 

CI 

Bl 

B2 

B2 

Ai 

♦ 

* 

N 

CI 

C2 

Bl 

B2 

B3 

Al 

* 

C 

CI 

C2 

C2 

Bl 

B2 

B3 

Al 

s . 

CI 

C2 

C2 

C2 

B2 

B2 

B3 

TS(BI) 

CI 

C2 

C2 

C2 

C2 

B2 

B2 

TS(SBI) 

CI 

C2 

C2 

C2 

C2 

Bl 

B2 

IC 

CI 

C2 

C2 

C2 

C2 

C2'-i 

B13 

MC 

CI 

C2 

C2 

C2 

C2 

C22 

lEnvironments  for  which  either  Cl  or  C2  is  given  are  for  systems  that  operate  in 
system  high  mode.  There  is  no  prescribed  minimum  level  of  trust  for  systems  that 
operate  in  dedicated  mode.  Categories  are  ignored  m  the  matrix,  except  for  their 
inclusion  at  the  TS  level. 

~\t  is  assumed  that  all  users  are  authorized  access  to  all  categories  on  the  system. 
If  some  users  are  not  authorized  for  ail  categories,  then  a  class  Bl  system  or  higher 
is  required. 

3Where  there  are  more  than  two  categories,  at  least  a  class  B2  system  is  required. 

U  =  Uncleared  or  Unclassified 

N  =-  Not  Cleared  but  .Authorized  Access  to  Sensitive  Unclassified  Information  or 

Not  Classified  but  Sensitive 

C  =  Confidential 

S  =  Secret 

TS  =  Top  Secret 

TS(BI)  =  Top  Secret  (Background  Investigation) 

TS  (SBI)  =  Top  Secret  (Special  Background  Investigation) 

IC  =  One  Category 

MC  =  Multiple  Categories 
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■feel  that  the  scheme  described  above  is  still  not  enough  in  assessing 
the  Navy's  security  needs.  Their  apprehension  can  certainly  be  extended 
to  the  entire  military  community. 

In  their  paper,  An  Approach  to  DetermininQ  Computer  Security 
Requirements  -for  Navy  Systems,  Landwehr  and  Lubbes  describe  a  method  -for 
applying  the  Orange  Book  to  represenat i ue  large-scale  dispersed  systems 
seen  in  the  Navy  and  propose  a  system  o-f  looking  at  risk  -factors  not 
previously  addressed  in  DoD'  literature  pertaining  to  trusted  systems. 
They  also  propose  a  scheme  -for  applying  these  risk  factors  to  assess  a 
system's  overall  risk  which  in  turn  will  be  the  basis  -for  the  security 
requirements  o-f  that  system.   A  discussion  o-f  their  ideas  -follow. 

1 .   Applying  Security  Requirements 

A  method  o-f  applying  the  computer  security  requirements  in  the 
Orange  Book  to  trusted  systems  is  depicted  in  Figure.  4.1  [Re-f.  11  :p.  3] 
and  de-fined  below: 

a.  extracting  -from  each  system  <or  system  design)  the  -factors 
that  a-f-fect  the  risk  that  its  operation  may  lead  to  the 
unauthorized  disclosure  o-f  sensitive  i  n-format  i  on  , 

b.  quanti-fying  these  -factors,  and 

c.  determining  system  security  requirements  (in  terms  o-f  the 
levels  de-fined  in  the  Orange  Book)  that  reduce  the  system 
risk  to  an  acceptable  level.  [Re-f.  ll:p.  21 

This  method   quali-fies   as   a   risk   evaluation   since   the   threat   o-f 

unauthorized  disclosure  o-f  sensitive  in-formation  exists.    The  system 

risk   is   a   mix   o-f   the   value   o-f   the   system's   assets   (sensitive 

in-formation),  the  system's  vulnerabilities,  and  the  clearance  o-f  the 

users. 
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System 
O«$cnption 


■  Extract - 


■Quantify 


Risk  Factors 

—  Locai  Processing 
Capability 

—  Communication  Path 

—  User  Capability 

—  Data  Exposure 

user  clearance 
data  classification 

—  Development/ 

maintenance 
environment 


Risk 
Evaluation 


Map 


Security  Design 
Requirements 

A1.  A8, 
831.  838 
C12 


Orange  Book  Criteria 
A     A1.A2....^n 

-if^r 

83   B31.B32....a3n 

-'•V 

82    —    —    — 

81    -    -    - 

C2   -    -    - 

CI   C11.C12 Cin 

Figure  4.1  -  Steps  in  Applying  Guidance 
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2.   Ident  i -fyinq  the  Risk  Factors 

Landwehr  and  Lubbes  propose  several  new  classes  o-f  risk  -factors 
that  at-fect  actual  system  risk  -  local  processing  capability, 
communication  path,  user  capability,  development/maintenance 
environment,  and  data  exposure.  Within  each  o-f  these  classes  is  a  list 
o-f  independent  risk  levels  that  represent  a  comparable  increase  or 
decrease  in  risk  between  adjacent  levels. 

Local  processing  capability  addresses  the  capabilities  o-f  the 
user's  terminal.  Capabilities  range  -from  the  receive-only  terminal  (no 
system  commands  can  be  entered  directly)  to  the  -f  i  xed--f  unc  t  i  on 
interactive  terminal  (allows  both  sending  and  receiving  i  n-format  i  on)  to 
the  programmable  terminal  (can  be  programmed  to  enter  commands).  The 
programmable  terminal  introduces  the  highest  level  o-f  risk  and  is  the 
equivalent  o-f  using  a  personal  computer  as  a  terminal.  The  identi-fied 
risk  levels  -for  local  processing  capability  are: 

Level  1:  receive-only  terminal 

Level  2:  -f  i  xed— funct  i  on  interactive  terminal 

Level  3:  programmable   device   (access   via   personal   computer   or 
programmable  host) 

The  comrriun  i  cat  i  ons   path  between   the  terminal  and  the  host  also 

a-f-fects  the  level  o-f  risk  in  the  system.   The  lowest  risk  level  exists 

in  terminal   that  has  a  simplex  receive-only  link   to   its  host  via 

store-and--forward  (3/F)   network   (e.g.,  -fleet  broadcast).    Terminals 

connected  to  the  host  directly,  through  a  local-area  network,  or  a 

long-haul  network  such  as  DDN  typi-fy  the  greatest  risk  o-f  penetration 

because   o-f   the   increased   bandwidths   and   closer   host-terminal 
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interactions    common    to    these    systems.       The     identified    r  i  sl<    levels    -for 
conrnun  i  cat  ions  path   are: 

Level  1:  store/forward,  receiye-only 

Level  2:  storeZ-forward,  send/receive 

Level  3:  interactive  (1/A),  via  direct  connection,  local-area  net, 
or  long-haul  packet  net 

A  system   that  allows  only  certain   prede-fined   inputs   is  less 

risky  than  a  system  that  responds  to  user  transactions.   Succinctly 

stated,  limiting  the  user's  capabilities  lessens  the  system  risk.   The 

identi-fied  risk  levels  -for  user  capability  are: 

Level  1 :  output  onl y 

Level  2:  transaction  processing 

Level  3:  -full  programming 

A  system  that  is  developed  and  maintained  by  cleared  individuals 
(commonly  seen  in  the  intelligence  community)  represents  a  lower  risk 
level  than  the  majority  o+  systems  that  are  developed  and  maintained 
without  this  requirement.  Using  this  assumption,  Landwehr  and  Lubbes 
consider  all  systems  to  have  been  developed  and  maintained  as  the 
majority,  in  an  open  environment.  There-fore,  no  risk  levels  are 
identi-fied  -for  the  development/maintenance  environment. 

The  greater  the  disparity  between  the  clearance  o-f  the 
least-cleared  user  and  the  cl  assi -f  i  cat  i  on  o-f  the  most  sensitive  data 
stored  or  processed  by  the  system,  the  greater  the  risk.  This  class  is 
similar  to  that  stated  above  by  the  DoD  Computer  Security  Center,  but  it 
is  termed  data  exposure  to  distinguish  it  -from  other  risk  -factors. 
Clearance  levels  are  identi-fied  as: 
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Le<^el  0:  uncleared 

Level  1:  uncleared,   but   authorized   access   to   sensitive 
classi-fied  i  n-format  i  on 

Level  2:  con-f  i  dent  i  al  clearance 

Level  3:  secret  clearance 

Level  4:  top  secret/background  investigation 

Level  5:  top  secret/special  background  investigation 

Level  6:    top   secret/special   background   investigation,   with 
authorization  -for  one  compartment 

Level  7:  top  secret/special  background  investigation,  with  more 
than  one  compartment 

Classification  levels  are  numbered: 

Level  0:  unci  assi -f  i  ed 

Level  1:  sensitive  unclassified  in-formation 

Level  2:  con-f  i  dent  i  al 

Level  3:  secret 

Level  4:  secret  with  one  category 

Level  5:  top  secret  with  no  categories,  or  secret  with  two  or 
more  categories 

Level  6:    top  secret  with  one  category 

Level  7i  top  secret  with  two  or  more  categories 
Data  exposure  is  computed  as  the  di-f-ference  between  the  level  o-f  the 
least-cleared  user  o-f  a  system  and  the  maximum  level  o-f  data  processed 
by  the  system.  The  range  o-f  values  is  -from  0  (all  users  cleared  -for  all 
data)  to  7  (uncleared  users  with  in-formation  being  processed  that  is  top 
secret  with  two  or  more  categories). 
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3.  Applying  the  Risk  Factors 

Once  the  various  risk  levels  have  been  determined  -for  a 
particular  system,  Tables  4.8,  4.9,  and  4.10  are  used  to  provide  the 
necessary  mappings  between  -factor  values,  risk  -factor  levels,  and 
security  requirements  as  presented  in  the  Orange  Book.  Local  processing 
capability  and  communication  path  provide  the  basis  -for  the  process 
coupling  risk  -  the  degree  to  which  a  process  can  maintain  its  integrity 
when  subjected  to  subversion  -from  an  outside  source  (Table  4.8).  A 
close  degree  o-f  interaction  results  in  a  high  degree  o-f  coupling  which 
yields  to  increased  vulnerability.  Coupling  the  process  coupling  risk 
with  user  capability  yields  an  overall  system  risk  that  is  independent 
o-f  the  data  exposure  (Table  4.9).  The  security  requirement  is  read  -from 
Table  4.10  as  the  result  o-f  relating  overall  system  risk  and  data 
exposure.  As  stated  previously  by  the  DoD  Computer  Security  Center, 
system  requirements  are  not  technically  -feasible  at  this  time  -for  all 
SI  tuat  i  ons. 

This  technique  is  superior  to  that  o-f  the  DoD  Computer  Security 
because  a  broader  range  o-f  threats  are  spec  i -f  i  cal  1  y  addressed.  System 
requirements  can  still  be  upgraded  i -f  the  environment  appears  to  pose 
unique  threats  that  have  not  been  addressed.  Landwehr  and  Lubbes  point 
out  that  approaches  -for  determining  other  security  requirement  (e.g., 
TEMPEST,  degaussing,  COMSEC,  contingency  planning)  are  beyond  the  scope 
o-f  their  approach. 
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TABLE  4.8  -  PROCESS  COUPLING  RISK 


Local  Processing 
Capability 

Communication  Path 

l.S/FNei 
(one-way) 

2.  S/F  Net 
(two-way) 

3.  I/A  Net  or  Direct 
Connection  (LAN.DDN) 

1.  Receive-only  terminal 

2' 

3 

4 

2.  Interactive  terminal 
(fixed  function) 

2 

4 

5-* 

3.  Programmable  device 
(Access  via  personal 
computer  or  programmable 
host) 

4 

5 

6' 

TABLE  4.9  -  SYSTEM  RISK 


User  Capability 

Process  Coupling  Risk 

2 

3 

4 

5 

6 

1.  Output-only  (subscriber) 

3' 

4 

5         6 

7 

2   Transaction  processing 

— 

5 

6 

7^ 

8 

3.  Full  programming 

— 

6 

7        8^ 

9* 

TABLE  4.10  -  MAPPING  SYSTEM  RISK  AND  DATA  EXPOSURE 
TO  ORANGE  BOOK  LEVELS 


Daia 

Exposure 

System  Risk 

3 

4 

5             6 

7 

8 

9 

0 

1     CI 

CI 

CI        C1/C2 

C2^ 

C2 

C2 

1 

|C1/C2 

C2 

C2 

C2 

C2/B1 

Bl 

Bl 

2 

C2 

C2/BI 

Bl            Bl 

Bl 

B1/B2* 

B2^ 

3 

Bl 

Bl 

BI/B2 

B2 

B2/B3 

B3 

B3/A1 

4 

82' 

B2/B3 

B3        B3/A1 

Al 

Al 

Al 

5 

B3/A1 

Al 

Al 

— 

— 

— 

— 

6 

— 

— 

— 

— 

— 

— 

— 

7 

~ 

— 

— 

— 

— 

— 

— 
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U.   MULTILEVEL  SECURITY  IN  THE  U.A.R.  LAB 

One  o-f  the  main  purposes  o-f  this  paper  is  to  i  ni-<es :  i  gate  the 
integration  o-f  the  Gemini  Trusted  Multiple  Microcomputer  Base  into  the 
Uargaming,  Analysis,  and  Research  <U.A.R.)  Lab.  Currently,  the 
acquisition  process  -for  a  Gemini  system  has  begun  with  an  estimated 
delivery  date  in  May  1986.  Primarily,  the  system  is  being  purchased  to 
become  the  basis  for  research  inuolying  multilei^el  security;  howeMer,  it 
is  worthwhile  to  search  -for  other  applications  that  can  enhance  or 
upgrade  the  current  security  posture  in  the  U.A.R.  lab. 
A.   THE  U.A.R.  LAB 

In  1977,  the  Uargaming,  Analysis,  and  Research  Lab  received 
sponsorship  -from  the  De-fense  Advanced  Projects  Research  Agency  (DARPA) 
as  a  research  center  -for  topics  involving  command,  control,  and 
communications  (C3)  .  j,^o  years  later,  the  lab  opened  with  a  PDP-11/70 
computer  and  GENESCO  graphics.  Today,  the  laboratory  is  a  modern, 
TEMPEST-hardened  -facility  with  signi-ficant  in-formation  processing  and 
storage  capability.  Appendix  C  details  the  current  systems/so-f  tware 
available  in  the  U.A.R.  lab. 

The  U.tt.R.  lab  is  currently  used  tor  wargaming,  classi-fied  thesis 
preparation,  course  projects,  and  research  activities.  The  -facMity  is 
o-f  prime  importance  in  the  USREDCGM's  development  o-f  the  Joint  Theater 
Level  Simulation  (JTLS)  development.   Also,  controlled  experiments  in 
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headquarters  e-f-fect  i  veness  are  conducted  periodically  by  the  De  +  ense 
Communications  Agency  <DCA). 

There  are  three  di-f  +  erent  wargaming  and  simulation  courses  taught 
twice  each  academic  year  at  the  Naval  Postgraduate  School.  These 
courses  involve  approximately  \60    students  -from  seven  curriculums  -  OR, 

^■^ ,  ASW,  EU),  Space  Ops,  Air  Ocean  Tactical  Environment  Support,  and  NSA. 
The  instruction  provided  to  o-f-ficer  students  covers  full  and  limited 
exposure  to  wargaming,  mathematical  modeling  and  simulation  techniques, 
decision  theory,  validation  o-f  models,  and  design  o-f  experiments. 
Thesis  and  pro-f  essi  onal  research  cover  such  diverse  areas  as  red  side 
planning  models,  ASW  modeling  and  computer  simulation,  computer  graphics 
enhancements.  Interactive  Battle  Group  Tactical  Trainer  (IB6TT)  and 
Naval  War-fare  Gaming  System  (NWGS)  model  validation,  distributed 
computing  with  large  and  small  networks,  and  voice-  input  devices  and 
techn  i  ques . 
B.   THE  GEMINI  TRUSTED  MULTIPLE  MICROCOMPUTER  BASE 

The  Gemini  Trusted  Multiple  Microcomputer  system  is  a  product  o-f 
Gemini  Computers,  Incorporated  o-f  Monterey,  Cali-fornia.  Up  to  eight 
iAPX286-based  microcomputers  can  be  modularly  connected  on  the  same 
Multibus  to  provide  a  combination  o-f  multilevel  security  and 
multiprogramming  capabilities.  The  system  can  provide  a  trusted  base  -for 
both  concurrent  and  real-time  applications  such  as  command,  control, 
communications,  intelligence,  weapons,  networks,  and  o+-fice  automation. 

The  Gemini  system  includes  the  Gemini  bus  controller,  a  real-time 
clock  with  battery,  and  data  encryption  device  using  the  standard 
NBS-DES  algorithm.   Non-volatile  memory  is  used  -for  storing  passwords 
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and  secret  encryption  keys.  The  Gemini  computer  system  supports  the 
■following  programming  languages:  Pascal  MT+ ,  JANUS  ADA,  PL/1,  C,  and 
Fortran . 

The  iAPX236  microprocessor  combines  the  central  processing  unit  and 
the  memory  management  unit  on  the  same  chip.  This  microprocessor 
supports  four  hierarchical  privilege  levels  -for  protection  and  mediation 
0+  all  memory  and  I/O  re+erences. 

The  Gemini  Multiprocessing  Secure  Operating  System  kGEMSOS)  stores 
all  in-formation  in  discrete  logical  objects  called  segments.  These 
segments  are  managed  with  respect  to  their  security  access  class  and 
access  mode.  GEMSOS  supports  both  sensitivity  and  integrity  access 
classes  ^each  with  3  levels  and  24  compartments)  tor  mandatory  security- 
policies.  Discretionary  security  policies  are  also  en+orced  on  an 
application-specific  basis. 

For   additional    information   on    the   Gemini   Trusted   Multiple 
Microcomputer  Base,  refer  to  Appendix  C  for  a  product  description 
(quoted  from  an  information  packet  from  Gemini  Computers,  Inc). 
C.   RISK  ASSESSMENT  IN  THE  U.A.R.  LAB 

This  risk  assessment  will  only  take  into  account  those  areas  most 
applicable  to  the  multilevel  secure  environment. 

1  .   Current  Assessment 

As  mentioned  previously,  the  W.A.R.  lab  operates  in  the 
"system-high"  security  mode.  All  personnel  that  are  authorized  access 
to  the  facility  must  possess  a  Secret  clearance  as  a  minimum  and  the 
highest  classification  of  information  stored  or  processed  by  all 
mainframe  computers  and  microcomputers   is  also  Secret.    The   only 
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discrepancy  existing  between  the  users'  minimum  clearance  and  the 
maximum  data  sensitivity  o-f  in-formation  stored  or  processed  in  the  lab 
is  that  o-f  need-to-know.  Obviously,  selective  exposure  to  classified 
material  is  desired  and  the  list  o-f  those  who  should  have  access  to  all 
in-formation  resident  in  the  -facility  is  small.  Passwords  to  directories 
and  -files  are  the  only  sa-feguard  -for  discretionary  dissemination  o-f  data 
and  their  compromise  can  result  -from  the  crowded  conditions  that  o-f  ten 
ej^ist  in  the  lab.  Along  with  the  problem  o-f  material  being  viewed  by 
those  who  should  not  have  discretionary  access,  a  greater  threat  o-f 
unintentional  or  malicious  tampering  o-f  either  programs  or  data  exists. 

At  the  present  time  the  only  I/O  external  to  the  physical 
con-fines  o-f  the  lab  is  a  secure  link  to  the  USREDCOM  at  McDill  AFB  in 
Florida.  Data  link  encryption  is  provided  by  a  crypto  generator 
(KG-34). 

2.   Proposed  U.A.R.  Lab  Operations 

Be-fore  proceeding  -further  with  a  look  at  risk  assessment,  it  is 
necessary  to  detail  some  o-f  the  possible  options  -for  con-figuration 
(minimum  user  clearance/maximum  data  sensitivity)  that  would  be  optimal 
-for  utilization  o-f  the  -facility.  These  proposed  con-figurations  are  made 
on  the  basis  o-f  three  assumptions:  the  lab  remains  at  its  current 
location  in  Room  157,  Ingersoll  Hall;  the  1 ab  s  role  as  a  research  and  a 
teaching  -facility  remains  unchanged;  and  the  highest  cl  assi -f  i  cat  i  on  o-f 
in-formation  being  stored  or  processed  in  order  to  -ful-fill  its  assigned 
role  continues  to  be  Secret. 

Option  1.  The  lab  continues  to  operate  in  the  "system-high 
mode",  but  with  greater  attention  towards  isolating  various  levels  o-f 
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in-formation  within  the  lab.  This  option  could  be  e-f-fect  i  yel  y 
implemented  without  the  introduction  o-f  new  hardware.  By  using  existing 
room  dividers  to  create  cells  -for  speci-fic  "types"  o+  work,  the 
e-f-fec  t  i  yeness  o-f  the  current  password  security  would  be  greatly  enhanced 
by  reducing  the  risk  o-f  accidental  compromise.  However,  such  an 
implementation  would  be  impractical  because  o-f  the  overcrowding  that 
o-ften  exists  in  the  lab.  During  the  conduct  o-f  wargames,  the  entire 
-facility  is  used  and  participants  are  o-ften  required  to  move  -freely 
between  cells. 

With  the  introduction  o-f  the  Gemini  Trusted  Multiple 
Microcomputer  Base,  selected  material  can  be  processed  and  stored  by  the 
system's  Trusted  Computing  Base  (TCB)  with  access  being  granted  only  to 
those  truly  authorized.  Such  material  can  be  routed  to  previously 
speci-fied  terminals  only.  Again,  this  is  not  a  -fix  to  the  current 
situation  in  the  lab,  but  rather,  an  alternative  -for  that  material  which 
truly  deserves  discretionary  isolation.  For  reasons  that  will  be 
explained  later,  not  all  in-formation  that  is  processed  or  stored  on  the 
current  main-frames  can  bene-fit  -from  the  discretionary  access  provided  by 
the  Gemini  Computer. 

Any  system  providing  multilevel  security  or  secure  guard  in  the 
above  situation  (both  open  and  closed  environments)  must  be  rated  Class 
C2  as  a  minimum.  Discretionary  access  is  provided  by  Class  C2  systems 
and  such  a  rating  is  the  minimum  -for  any  system  that  processes  sensitive 
or  classi-fied  in-formation. 

Option  2.  The  lab  continues  to  operate  in  a  "system-high"  mode 
with  increased  emphasis  on  discretionary  isolation.   To  alleviate  the 
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■frequent  overcrowded  conditions,  an  additional  room  has  been  physically 
secured  elsewhere  in  Ingersoll  Hall.  Personnel  who  are  not  directly 
inwolved  in  wargaming  can  conduct  research  or  assignments  outside  the 
U.A.R.  lab  proper. 

Most  o-f  the  comments  stated  concerning  Option  1  are  applicable 
to  this  con-figuration.  Again,  a  system  with  a  rating  o+  Class  C2  is 
su-f-ficient  -for  establishing  a  multilevel  secure  or  guard  environment.  An 
additional  consideration  is  the  method  or  medium  by  which  sensitive 
in-formation  is  sent  to  the  add-on  work  area.  Physical  security  o-f  the 
transmission  medium  or  data  encryption  is  required  to  prevent  possible 
compromi  se . 

Local  processing  capability  and  user  capability  can  be  tailored 
-for  each  terminal  allowing  varying  degrees  o-f  interaction  with  the  host 
computer.  Such  complicating  -factors  lend  greater  support  -for  the 
proposed  risk  assessment  scheme  by  Landwehr  and  Lubbes.  Their  scheme 
examines  the  risk  level  -for  more  -factors  than  that  o-f  the  DoD  Computer 
Security  Center.  In  this  case,  a  system  with  a  rating  o-f  Class  C2  is 
still  considered  adequate. 

The  same  caveat  applies  as  be-fore.  Not  all  in-formation  stored 
or  processed  by  the  current  lab's  ma  in -frame  computers  will  benefit  -from 
the  discretionary  access  controls  en-forced  by  the  Gemini  computer. 

Option  3.  This  option  is  the  most  ambitious  and  desirable  o-f 
all  the  options  presented.  The  computer  security  environment  in  the 
UI.A.R.  lab  is  one  o-f  total  multilevel  security.  Terminals  are  available 
outside  o-f  the  -facility  (classrooms,  workspaces,  and  o-f-fices)  -for 
various  levels  o-f  work  utilizing  the  lab's  resources.    In  secure  and 
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unsecure  workspaces,  the  local  processing  capability  and  the  user 
capability  o-f  each  terminal  is  tailored  to  meet  speci  +  ic  requirements  as 
in  Option  2.  Uncleared  users  may  even  be  given  authorization  to  use 
terminals  that  are  placed  in  unsecure  workspaces. 

I-f  these  capabilities  existed  in  the  current  lab,  overcrowding 
would  no  longer  be  a  problem.  Students  could  enter  the  unci  assi -f  i  ed 
portions  o-f  their  papers  outside  the  lab.  Instructors  could  set 
parameters  -for  upcoming  wargames  in  the  convenience  of  their  o-f+ice. 
Classroom  instruction  could  be  conducted  outside  o-f  the  -facility.  Also, 
the  lab's  role  could  be  enhanced  greatly.  Allied  students  would  be  able 
to  participate  in  ongoing  classi-fied  wargames  since  all  sensitive 
material  would  be  removed  prior  to  display  on  a  terminal  designated  -for 
uncleared  users.  Instruction  requiring  the  lab's  resources  would  not  be 
limited  to  those  with  appropriate  clearances.  Many  more  examples  could 
be  c  i  ted. 

The  application  o-f  the  Computer  Security  Center's  approach  to 
risk  assessment  requires  the  minimum  criteria  class  -for  a  system  that 
can  support  the  con-figuration  stated  in  Option  3  is  Class  B3  -for  the 
open  environment  and  Class  B2  -for  the  closed  environment.  Again,  the 
Landwehr  and  Lubbes  scheme  is  more  appropriate.  I-f  one  chooses  the 
-factor  yielding  the  lowest  risk  levels  -for  each  category  (e.g.,  a 
receive-only  terminal,  S/F  Net  (one-way),  user  output  only),  it  is 
possible  to  have  a  Class  Bl  system.  Given  the  constraints  leading  to 
the  low  risk  levels,  the  con-figuration  o-f  Option  3  can  be  realized  with 
an  unbearably  low  e-f-fect  i  veness.  A  Class  B3  system  is  required  when  the 
-factors  yielding  the  greatest  risk  level  -for  each  category  is  selected. 
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The  Computer  Security  scheme  assumes  maximum  risk  and  does  not  enumerate 
the  various  -factors.  The  Landwehr  and  Lubbes  scheme  evaluates  the 
various  -factors,  giving  more  -flexibility  in  con-figuration  design. 

The  Gemini  Trusted  Multiple  Microcomputer  Base  is  currently 
undergoing  -final  evaluation  -for  the  Class  B3  rating.  It  was  developed 
as  a  "bolt-on"  system  to  provide  multilevel  security,  but  will  its 
integration  into  the  W.A.R.  lab  produce  the  ambitious  results  needed  to 
realize  the  con-f  i  gurat  i  on  "stated  in  Option  3? 
D.   INTEGRATION  OF  THE  GEMINI  COTIPUTER  INTO  THE  U.A.R.  LAB 

The  Gemini  Trusted  Multiple  Microcomputer  Base  can  serve  merely  as 
a  secure  guard  or  can  be  the  basis  -for  a  total  multilevel  secure 
env  i  ronmen t . 

1 .  The  Gemini  Computer  as  a  Secure  Guard 

The  role  o-f  a  secure  guard  system  is  very  similar  to  that  o-f  a 
multilevel  secure  system.  The  major  -function  of  both  is  to  allow 
subjects  o-f  di-f-ferent  levels  of  classification  to  operate  on  a  common 
computer  system  or  network.  All  of  the  above  options  present  situations 
that  require  guard  technology  -  mandatory  and  discretionary  access. 

The  Gemini  computer's  TCB  is  responsible  for  insuring  that 
only  authorized  subjects  have  access  to  information  stored  and  processed 
on  the  system.  The  system  has  the  capability  of  both  storing  and 
processing.  A  digital  signature  (label)  placed  on  each  object 
determines  which  subjects  ultimately  have  access  and  the  terms  of  that 
access.  It  is  clear  that  all  information  created,  stored,  or  processed 
on  the  Gemini  system  can  be  manipulated  in  the  multilevel  secure 
environment.   However,  when  the  Gemini  system  is  integrated  with  the 
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existing  computers  in  the  lab,  this  integrity  cannot  necessarily  be 
i  nsured. 

Since  existing  computers  in  the  lab  do  not  have  a  TCB,  resident 
so-ftware  cannot  legitimately  label  objects  and  access  by  subjects 
(especially  processes)  to  existing  labelled  objects  cannot  be  tolerated. 
There-fore,  in  order  to  maintain  information  integrity,  the  only 
allowable  integration  o-f  the  Gemini  system  with  existing  computer 
systems  in  the  Tab  is  with  partitioned  memory  sections  on  these  existing 
systems.  All  information  flow  that  is  under  the  umbrella  of  the  guard 
interface  must  go  through  the  Gemini  computer  for  rou ■  ~q  to  authorized 
subjects  only  and  existing  systems  can  be  used  for  storage  only.  In 
summation,  the  Gemini  computer  can  only  serve  as  a  guard  device  for  a 
predetermined  subset  of  the  information  that  is  created,  stored,  or 
processed  in  the  facility. 

2.   The  Gemini  Computer  as  a  Basis  For  Multilevel  Security 

Other  than  the  research  aspect,  Gemini's  greatest  contribution 
would  be  the  capability  of  providing  a  multilevel  secure  environment  for 
all  information  handling  functions  in  the  W.A.R.  lab.  Unfortunately, 
without  the  prohibitive  investment  of  several  man-years,  the  existing 
systems  and  resident  software  cannot  qualify  for  the  stringent 
requirements  demanded  by  the  Gemini's  TCB.  Most  of  the  reasons  were 
mentioned  in  the  previous  section.  Primarily,  existing  systems  do  not 
have  a  TCB  and  the  complexity  of  resident  software  (esp.  operating 
systems  and  wargames)  make  it  extremely  difficult  for  them  to  be  adapted 
to  the  Gemini  system. 
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In  order  to  maintain  a  sphere  with  multilevel  security,  the 
Gemini  base  must  be  used  for  creating,  storing,  or  processing  all 
information  that  is  to  be  dynamic  within  the  environment.  The  Gemini 
system  supports  several  processors  and  memory  expansion  to  provide  a 
complete  multilevel  secure  system  within  itself.  Also,  memory  can  be 
partitioned  on  the  existing  system  for  exclusive  use  by  the  Gemini 
system.  A  major  drawback  is  the  fact  that  future  software  development 
must  proceed  around  the  requirements  of  the  Gemini  system.  Until  such  a 
system  is  standardized  in  the  military  community,  transportability  of 
software  will  be  limited. 

The  shortcomings  listed  are  not  only  associated  with  the  Gemini 
system,  but  rather  apply  to  all  "bolt-on"  multilevel  secure  systems. 
They  are  not  indicative  of  a  lack  of  sophistication,  but  of  the 
complexity  of  providing  multilevel  security. 
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VI.   CONCLUSION 

A.   CONCLUDING  REMARKS 

The  original  intent  o-f  this  paper  was  to  examine  the  integration  o+ 
the  Gemini  Trusted  Multiple  Microcomputer  Base  into  the  W.A.R.  lab  and 
to  develop  a  -framework  -for  converting  the  -facility  into  a  multilevel 
secure  environment.  During  the  research  phase  o-f  preparing  this  paper, 
it  was  discovered  that  the  so-called  "bolt-on"  security  systems 
currently  available  are  extremely  limited  as  a  means  -for  creating  a 
multilevel  secure  environment  i -f  the  goal  is  to  use  the  processing 
capability  and  resident  so-ftware  of  existing  computing  systems.  Thus, 
the  direction  o-f  this  paper  was  changed  to  assess  the  security  risk 
currently  associated  with  the  UI.A.R.  lab  and  to  establish  bounds  -for  the 
integration  o-f  the  Gemini  system. 

The  need  -for  a  multilevel  secure  environment  continues  to  be  a 
limiting  -factor  in  the  realization  o-f  the  -full  potential  o-f  automated 
data  processing  systems  used  -for  sensitive  i  n-f  ormat  i  on .  Given  the 
complexity  o-f  the  security  problem  and  the  sa-feguards  that  are  en-forced 
by  the  Trusted  Computing  Base  (TCB)  ,  it  is  unlikely  that  any  retro-fitted 
security  system  can  be  meshed  with  an  existing  computer  system  and  its 
resident  so-ftware  to  produce  a  complete  multilevel  secure  environment. 
"Bottom-up"  design,  as  seen  in  the  Blacker  project,  appears  to  be  the 
best  alternative  -for  '■>er-/    large  in-formation  processing  systems. 
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The  integration  o-f  the  Gemini  Trusted  Multiple  Microcomputer  Base 
into  the  U.A.R.  lab  will  not  convert  the  -facility  into  a  complete 
multilevel  secure  environment.  However,  the  Gemini  system  is  a 
•formidable  in-formation  processing  system  that  can  provide  a  multilevel 
secure  environment  by  itsel-f.  Also,  the  Gemini  system's  capabilities 
can  be  greatly  enhanced  by  the  addition  o-f  multiple  processors  and 
in-formation  storage  devices.  Discounting  the  research  opportunities, 
the  Gemini  system^'s  greatest  contribution  to  the  U.A.R.  lab  will  be  its 
role  as  a  secure  guard  -for  en-forcing  discretionary  access. 
B.   RECOMMENDATIONS  FOR  FOLLOW-ON  STUDY 

The  Gemini  system  will  provide  an  excellent  vehicle  -for  graduate 
level  research  for  both  centralized  and  distributed  secure  in-formation 
processing  in  the  C3I  environment.  The  Computer  Science  Department  is 
currently  conducting  research  on  a  Gemini  system  that  was  recently 
acquired;  thus,  a  close  liaison  must  be  maintained  with  the  Computer 
Science  Department  to  prevent  duplication  o-f  e-f-fort.  A  clear  division 
o-f  work  should  be  established.  The  Command  and  Control  curriculum 
should  restrict  research  projects  to  those  that  are  application  (system 
level)  or  security  policy  oriented. 

The  -following  is  a  suggestive  list  o-f  -feasible  areas  o-f  study. 

1 .  Integration  into  existing  untrusted  systems  -  There  are 
many  untrusted  in-formation  processing  systems  within  the 
Department  o-f  De-fense  that  could  bene-fit  -from  "guard" 
technology.  The  need  to  pass  in-formation  between  untrusted 
systems  at  different  security  levels  is  great  and  becoming 
increasingly  more  necessary  at  all  levels  within  the  armed 
forces.  This  ability  could  also  eliminate  some  of  the 
redundancy  seen  in  existing  systems.  The  development  and 
demonstration  of  a  trusted  "guard"  device  between  The  Marine 
Corps  Tactical  Combat  System  (TCO)  and  the  Marine  Air  Ground 
Intelligence  System  (MAGIS)  is  one  example. 


77 


MAGIS  is  an  integrated  tactical  data  system  which  will 
provide  the  Marine  commander  with  timely,  accurate  and 
complete  all-source  intelligence  on  which  to  base  tactical 
decisions.  TCO  will  be  an  on-line,  interactiue,  secure 
tactical  command  and  control  system  designed  to  enhance  the 
capability  o-f  the  commander  and  his  operational  sta-ft  to 
conduct  combat  operations  and  planning.  TCO''s  role  is  below 
wing  and  division  level  where  MAGIS  is  not  resident.  The 
need  exists  -for  a  security  device  which  provides  a  virtual 
link  between  end-user  (TCO)  to  end-user  (MAGIS)  but  can 
cause  a  physical  break  in  order  to  allow  message  tra-f-fic 
between  SCI  and  non-SCI  systems.  The  TCO  will  serve  as  the 
primary  source  o-f  in-formation  -for  MAGIS. 

2.  Reduction  in  throughput  -  '  Obviously,  the  additional 
processing  required  to  en-force  a  wel  1 --formul  ated  security 
policy  reduces  the  total  throughput  o-f  the  system.  The 
degree  o-f  security  labelling  can  range  -from  the  byte  level, 
to  the  word  level,  to  the  -file  level.  The  lower  the  level 
that  labelling  is  required,  the  greater  the  cost  in 
throughput  time.  Research  is  needed  to  establish  how  much 
degradation  in  throughput  can  be  tolerated  -for  individual 
applications  and  to  examine  the  trade-o-f-fs. 

3.  Policies  concerning  data  aqgreQation  -  It  is  possible  -for 
an  aggregate  set  o-f  data  elements  to  be  o-f  a  higher 
sensitivity  level  than  those  data  elements  taken 
individually.  Areas  where  this  situation  is  likely  to  be  a 
problem  need  to  be  identi-fied  and  sa-feguards  developed. 

Regardless  o-f  the  area  o-f  study,  the  researcher  must  be  aware  o-f  the 

considerations  discussed  during  the  risk  assessment  chapter  and  answer 

the  question:  "Is  the  level  o-f  e-f-fort  (both  time  and  money)  required  to 

achieve  the  desired  security  environment  commensurate  to  the  value  o-f 

the  protected  i  n-format  i  on?" 
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APPENDIX  A  -  SECURITY  MODES  OF  OPERATION 

DoD  computer  security  policy  identi-fies  -five  modes  o-f  operation  to 

accredit  automated  systems  that  process  classified  information: 

Dedicated  -  All  system  equipment  is  used  exclusively  by  that 
system  and  all  user's  have  equal  access  (both  level-  o-f 
classification  and  need-to-know)  to  the  information  on  that 
system. 

System  High  -  All  system  equipment  is  protected  at  the  level 
of  the  most  sensitive  information  that  is  processed  by  that 
equipment.  Users  are  cleared  to  that  level,  but  may  not  meet 
need-to-know  requirements  for  some  of  the  information. 

Multilevel  -  The  environment  is  the  same  as  the  controlled  - 
users  without  the  proper  level  of  clearance  and/or  need-to-know 
for  all  information  that  is  processed  on  the  system;  however,  in 
this  mode,  the  operating  system  and  associated  system  software 
are  responsible  for  the  separation  of  users  and  classified 
mater  i  al . 

Controlled  -  System  users  do  , not  necessarily  have  the  proper 
level  of  clearance  andy^or  need-to-know  for  all  information  that 
is  processed  on  the  system.  The  burden  of  separation  of  users 
and  classified  information  is  not  essentially  under  operating 
system  control  . 

Cwnpartmented  -  System  allows  two  or  more  types  of 
compartmented  information  or  any  one  type  of  compar tmented 
information  with  other  than  compartmented  information  to  be 
processed.  System  access  is  secured  to  at  least  Top  Secret,  but 
all  users  need  not  be  formally  authorized  access  to  all  types  of 
compartmented  information  being  processed  and/or  stored  in  the 
system. 

Additional   policies  may  be   defined   to  reflect   the   needs  of   the 

individual  services. 
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APPENDIX  B  -  SECURITY  CLEARANCES 

The  -following  is  a  detailed  description  o-f  security  clearances  as 
used  by  the  DoD  Computer  Security  Center: 

a.  Uncleared  <U)  -  Personnel  with  no  clearance  or 
authorization.  Permitted  access  to  any  information  -for 
which  there  are  no  speci-fied  controls,  such  as  openly 
published  i  n-format  i  on  . 

b.  Unci  assi -f  i  ed  In-formation  <N)  -  Personnel  who  are  authorized 
access  to  sensitive  unci  assi -f  i  ed  (e.g.,  For  0-fficial  Use 
Only  (FOUO))  in-formation,  either  by  an  explicit  o-f-ficial 
authorization  or  by  an  implicit  derived  -from  of-ficial 
assignments  or  responsibilities. 

c.  Confidential  Clearance  (C)  -  Requires  U.S.  citizenship  and 
typically  some  limited  records  checking.  In  some  cases,  a 
National  Agency  Check  (MAC)  is  required  (e.g.,  -for  U.S. 
citizens  employed  by  colleges  or  universities). 

d.  Secret  Clearance  (S)  -  Typically  requires  a  NAC,  which 
consists  o-f  seaj^ching  the  Federal  Bureau  o-f  Investigation 
■fingerprint  and  investigative  -files  and  the  De-fense  Central 
Index  o-f  Investigations.  In  some  cases,  -further 
investigation  is  required. 

e.  Top  Secret  Clearance  based  on  a  current  Background 
Investigation  (TS(BI))  -  Requires  and  investigation  that 
consists  o-f  a  NAC,  personal  contacts,  record  searches,  and 
written   inquiries.     A   BI   typically   includes   an 

investigation  extending  back  5  years,  o-f  ten  with  a  spot 
check  investigation  extending  back  15  years. 

-f .  Top  Secret  Clearance  based  on  a  current  Special  Background 
Investigation  (TS(SBI))  -  Requires  an  investigation  that, 
in  addition  to  the  investigation  -for  a  BI  ,  includes 
additional  checks  on  the  subject's  immediate  -family  (  i -f 
•foreign  born)  and  spouse  and  neighborhood  investigations  to 
veri-fy  each  o-f  the  subject's  -former  residences  in  the 
United  States  where  he  resided  six  months  or  more.  An  SBI 
typically  includes  an  investigation  extending  back  15 
years.  [Re-f.  10:p.  2?] 


SO 


The  -following  two  categories  are  actually  authorizations  rather  than 

clearance  levels,  but  they  are  included  to  emphasize  their  importance. 

g.  One  category  (IC)  -  In  addition  to  a  TS(SBI)  clearance, 
written  authorization  -for  access  to  one  category  o+ 
in-formation  is  required.  Authorizations  are  the  access 
rights  granted  to  a  user  by  a  responsible  individual  (e.g., 
secur  i  ty  o-f-f  i  cer)  . 

h.  Multiple  categories  (MO  -  In  addition  to  TS<SBI) 
clearance,  written  authorization  -For  access  to  multiple 
categories  o-f  in-formation  is  required.  [Re-f.  10:p.  28] 

Data  sensitivies  or  classifications  can  also  be  de-fined  that  are  grouped 

using  the  same  hierarchy  as  above,   but  are  not  limited  to  these 

categories.   NOFORN  is  one  such  nonh i erarch i cal  sensitivity  category. 
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APPENDIX  C  -  PROJECTS  TO  DEUELQP  TRUSTED  SYSTEMS 


Appendix  C  consists  o-f  three  tables  extracted  -from  Carl  E. 
Landwehr's  "The  Best  Available  Technology  for  Computer  Security"  which 
appeared  in  the  July  1983  issue  o-f  Computer  magazine. 

Table  C.l  -  Completed  Projects  to  De^^elop  Trusted  Systems 

Table  C.2  -  Projects  Underway  to  Develop  Trusted  Systems 

Table  C.3  -  Abbreviations  Used  in  Appendix  C 
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TABLE  C.3  -  ABBREVIATIONS  USED  IN  APPENDIX  C 


Notes: 

'    data  unknown  or  uncertain 

[|    enclosed  data  indicates  plans,  not  accomplishments 

Abbreviations: 

AF  Air  Force 

AFDSC  Air  Force  Data  Services  Center 

asm  Assemtjly  language  (tor  machine  indicated) 

BBN  Bolt  Beranek  and  Newman.  Inc. 
Boyer-Moore    Boyer-Moore  ttieorem  prover  (SRI) 

CIA  Central  Intelligence  Agency 

Cincpac  Commander-in-Ctiiet  Pacific 

CSC  Computer  Sciences  Corp 

DARPA  Defense  Advanced  Research  Projects  Agency 

DEC  Digital  Equioment  Corp. 

Demo  System  Ouilt  as  prototype  or  demonstrator  only 

DCA  Defense  Communications  Agency 

FACC  Ford  Aerospace  and  Comm  Corp. 

FCOSSA  Fleet  Combat  Direction  Systems  Support  Activity 

Forscom  Forces  Command  (Army) 

ISI  Information  Sciences  institute 

ITP  Interactive  theorem  prover  (SOC) 

MARi  Microprocessor  Applications  Research  Institute  (England) 

MOL/360  Machine  Oriented  Language  tor  IBM/360 

NASA  National  Aeronautics  and  Space  Administration 

NB  System  never  built 

NC  System  not  yet  complete  enough  for  evaluation 

NSA  National  Security  Agency 

RSRE  Royal  Signals  and  Radar  Establishment  (Malvern. -England) 

SOC  System  Development  Corporation 

SDL  System  Designers.  Ltd   (England) 

SLS  Second  level  specification 

SRI  SRI  International 

TLS  Top-level  specification 

VMS  Operating  system  lor  DEC  VAX  computer 

WiS/JPM  WWMCCS  joint  program  manager 

WSE  WWMCCS  system  engineer 

WWMCCS  World-Wide  Military  Command  and  Control  System 

3LS  Third-level  specification 
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APPENDIX  D  -  U.A.R.  LAB  COMPUTING  RESOURCES 

A.  PROCESSING  HARDWARE 

(1)  UAX  -  11/780  with: 

6   MB  Main  Memory 

1200  MB  "Jirtual  Disk  Memory 

High  Speed  Printer 

16  Termi  nal s 
<3)   RATiTEK  Hi-Res  Graphics  Systems  with: 

Dual  Monitors 

Tablets 
<3)   UICAT/NA'v'TAG  Microprocessor-based  Tactical  Trainers 

B.  COMMUNICATION  HARDWARE 

(1)   Private  Line  Inter-face  <PLI) 
(1)   Crypto  Generator  (KG-34:) 
<1)   ARPATvlET  IMP  (C-30) 
G.   SOFTWARE/FIRMWARE 

•v/iAX  'v'MS  Operating  System  with: 

Fortran  77  Compiler   (For  NWISS/TBGTT  Deuel opment) 

Simscript  Compiler    (For  JTLS  Development) 
Berkeley  UNIX  (4.1  BSD)  with: 

C  Comp  i 1 er 

Pascal  Compiler 

Lisp  Environment 
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Graphics  Tools  Package  (DI-3000) 
Statistical  Tools  Package  (SPSS-X) 

D.  SIMULATIONS/MODELS 

NUISS  <IB6TT) 

JTLS 

GOMEL 

WAAM  (Incomplete) 

JANUS  (Replay  Files  Only) 

E.  MICROSYSTEMS 

Fleet  Mission  Program  Library 

Decision  Aids  Implemented  On: 
HP  9020  (Standard) 
Others  (Wang,  Tandy) 
NAUTAG 

Sur  +  ace  Uar-fare  Trainer 
Microcomputer  Graphics 

'^/'ideodisc  Map  Overlay. 
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APPENDIX  E  -  GEMINI  TRUSTED  MULTIPLE  MICROCOMPUTER  BASE  - 

PRODUCT  DESCRIPTIOr>l 


CAPABILITIES: 


Concurrent  computing.  Gemini  operating  system  supports  up  to  8 
power-ful  iAPX286  processors  -for  combined  parallel  and  pipeline 
concurrent  processing. 

Flexible  multilevel  security.  Designed  as  DoD  Class  B3 
multiprocessing  security  kernel,  coded  in  Pascal,  with 
hardware-supported  DES  encryption. 

Con-figuration  independence.  Supports  various  con-figurations 
-from  a  real-time  dedicated  controller  to  a  multi-user 
workstat  i  on . 

SeH-hosted  so-ftware  development.  Disk-based  CP/M  enuironment 
and  Gemini  toe's  -for  applications  in  Pascal,  JANUS  ADA,  C,  PL/ 1 
and  FORTRAr>l. 

ARCHITECTURE: 

JEEE  Standard  796   Multibus. 

Microcomputers  based  on  the  Intel  iAPX236  microprocessor  with 
CPU  and  MMU  on  one  chip. 

Up  to  8  microcomputers  tightly  coupled  on  bus. 

Up  to  2  Mbytes  local  RAM  per  microcomputer. 

Up  to  8  Mbytes  shared  global  memory  per  system. 

Up  to  4  disk  drives  with  any  mix  o-f  -fixed  l-Jinchester,  removable 
Uinchester  and  -floppy  diskettes. 

Up  to  24  RS-232  serial  I/O  inter-face  ports. 

Real-time  calendar  clock  with  battery  backup. 

High  speed  DES  data  encryption  hardware. 

Non-volatile  system  password  and  encryption  key  storage. 
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SYSTEM  SOFTWARE: 

Gemini   Multiprocessing   Secure   Operating   System   (GEM30S). 
Compatible  in  all  con-figurations. 

Separation   and  sharing  o-f   data  based  on   sensitivity  and 
integrity  levels  and  compartments. 

DoD  Computer  Security  Center  Development  Product  Evaluation  in 
progress . 

Convenient   inter-face   to   GEMSOS   -for   concurrent   computing 
application  programs  in  several  programming  languages. 

Gemini  development  tools  -for  concurrent  computing  applications. 

Same   GEMSOS   on   every   processor.     Completely   distributed 
operat  i  ng  system. 
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